Unable to specify a subdirectory for assembly loading

Steps to reproduce

Build a project for .NET Core 3. Add some nuget package. Create a “lib” subdirectory in the output folder. Move some/all of the .dll files into “lib”. Program will fail to run, as it is unable to locate the moved assemblies.

Details

When building a program using the standard framework, which used app.exe.config for its runtime configuration, you could specify private subdirectories that would be searched when resolving assembly loading:

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

I have been unable to find any directives that would reproduce that behavior in the new app.runtimeconfig.json configuration. The runtime spec documentation only mentions searching the root application directory, and doesn’t indicate any means of getting the runtime to search alternate directories (even with the presumed restriction of only being allowed to search private subdirectories).

Use of additionalProbingPaths in app.runtimeconfig.json and app.runtimeconfig.dev.json does not seem to work.

Environment data

dotnet --info output:

.NET Core SDK (reflecting any global.json): Version: 3.0.100-preview6-012264 Commit: be3f0c1a03

Runtime Environment: OS Name: Windows OS Version: 6.1.7601 OS Platform: Windows RID: win7-x64 Base Path: C:\Program Files\dotnet\sdk\3.0.100-preview6-012264\

Host (useful for support): Version: 3.0.0-preview6-27804-01 Commit: fdf81c6faf

.NET Core SDKs installed: 1.1.14 [C:\Program Files\dotnet\sdk] 2.1.602 [C:\Program Files\dotnet\sdk] 2.1.604 [C:\Program Files\dotnet\sdk] 2.1.700 [C:\Program Files\dotnet\sdk] 2.1.800-preview-009696 [C:\Program Files\dotnet\sdk] 2.2.202 [C:\Program Files\dotnet\sdk] 2.2.204 [C:\Program Files\dotnet\sdk] 2.2.300 [C:\Program Files\dotnet\sdk] 2.2.400-preview-010219 [C:\Program Files\dotnet\sdk] 3.0.100-preview6-012264 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed: Microsoft.AspNetCore.All 2.1.9 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All] Microsoft.AspNetCore.All 2.1.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All] Microsoft.AspNetCore.All 2.2.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All] Microsoft.AspNetCore.All 2.2.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All] Microsoft.AspNetCore.App 2.1.9 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 2.1.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 2.2.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 2.2.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 3.0.0-preview6.19307.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.NETCore.App 1.0.16 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 1.1.13 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 2.1.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 2.1.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 2.2.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 2.2.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 3.0.0-preview6-27804-01 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.WindowsDesktop.App 3.0.0-preview6-27804-01 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

[0xd4d]

That workaround is ugly and requires too much work.

@Kinematics I’ve successfully removed all files from the root folder and put them in the bin folder. The only thing remaining are the apphost exe files. Nothing else. I already mentioned it above but here’s some more info.

The apphost exe (eg. myapp.exe if your entry point assembly is myapp.dll) has the path to your main dll file. You can patch the apphost exe so instead of having the path myapp.dll in it, it’s bin\myapp.dll. When the exe is started, it will load your file from the bin folder. This is the patcher I use. What’s left is just moving the output to the bin folder and moving the apphost exe to the root and you’re done.

Moving your files to a bin folder is a common request and the SDK should have support for this. All it needs to do is move all files to the bin folder and make sure the apphost exe loads the file from the bin folder.

[Symbai]

.NET 6 don’t solve this problem, sorry. And I don’t believe .NET 7 will do so, it seems to be very low priority, sadly. Good news is that the unofficial solutions here still work with .NET 6 and some of them are extremely easy to apply. The only official “solution” for this mess is publishing as single-file, well let’s call it workaround to be clear, for the cost of startup performance. If you haven’t already you should upvote the first post. With only 7 upvotes I’m not surprised about its being low priority…