1

I have a project referencing several other self-built projects. I want to move all my DLLs to a specific subfolder "DLLs". I found this article and did it the same way:

Build DLL to a separate folder

So I defined a new section in my App.config:

<runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <probing privatePath="DLLs" />
    </assemblyBinding>
</runtime>

And I moved all DLLs to a specific output folder using a post-build event:

mkdir "$(TargetDir)DLLs"
move /Y "$(TargetDir)\*.dll" "$(TargetDir)DLLs\"
move /Y "$(TargetDir)\*.pdb" "$(TargetDir)DLLs\"

I checked the DLLs are actually moved to the specified "DLLs" folder in the output directory. But the program will not start. The following error was shown in the Debug output:

"The target process exited without raising a CoreCLR started event. Ensure that the target process is configured to use .NET Core. This may be expected if the target process did not run on .NET Core. The program '[12396] MyProg.exe' has exited with code 2147516570 (0x8000809a)."

Please note that I am working with .NET 6, so .NET Core is not applicable for me.

What could be the cause for this problem?

Thern
  • 1,017
  • 8
  • 17
  • 1
    Is the goal to reduce the number of files in the executable folder? If so you might want to consider using "Single-file deployment" instead. – JonasH Aug 18 '23 at 08:15
  • If you moved the assemblies into a sub-folder, the default mechanism to load assemblies can't find them. You have to attach to the `AppDomain.AssemblyResolve` event and load to assembly by yourself into memory. – Oliver Aug 18 '23 at 08:16
  • @Oliver But where to put this? The program doesn't even start, so even if I define the AppDomain.AssemblyResolve event into my App.xaml.cs, it will never get executed. – Thern Aug 18 '23 at 08:18
  • 1
    @JonasH The requirement of the customer is to batch verify all DLLs against a checksum, so I wanted to put them all into one folder and run a checksum verification against that folder. However, single file deployment may be an even better solution, this would remove the need to check any DLL, and it is unwanted to retroactively change DLLs in the output folder anyway. Need to investigate that option. – Thern Aug 18 '23 at 08:21
  • 2
    I would ask the customer what the real requirements are. There are builtin features in .net, like assembly signing and "Strong-named assemblies", and deterministic compilation, as well as installing the program into a folder with restricted access, that all help provide security and auditability. Generating a checksum sounds like it is for security or auditability, but it also does not sound very secure. – JonasH Aug 18 '23 at 08:35

1 Answers1

-1

If you want to place all dlls in a separate folder, there is another way without using post-build event:

  1. You need to define a new section in your App.config:

     <runtime>
  <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <probing privatePath="DLLs" />
  </assemblyBinding>
 </runtime>

  2. Create a Directory.Build.props file in your project root directory (csproj layer directory), and add to it:

    <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
 <ItemDefinitionGroup>
  <Reference>
   <Private>False</Private>
  </Reference>
 </ItemDefinitionGroup>
</Project>

enter image description here

  1. Re-open your project at this time and you will find that the copy local of all the dlls used are set to false

  2. At this point, debugging the project will put the dll into the folder you specified

wenbingeng-MSFT
  • 1,546
  • 1
  • 1
  • 8
  • I think you might have misunderstood the question. I can easily put all DLLs into a separate folder, but the application will not find them at runtime. I solved this now by publishing the executable as a single file with all DLLs built in; this way, a check for all DLL versions is not necessary. However, while this is a solution to my problem, it is no solution for the question. – Thern Aug 21 '23 at 15:39
  • Originally, I thought that the problem was that the project could not apply the dll after the post-build event, so I suggested using other methods. But single file deployment is indeed a better solution – wenbingeng-MSFT Aug 22 '23 at 06:57