sdk: Unable to specify a subdirectory for assembly loading

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.

Because the .NET team probably didn’t thought this could be an issue for developers and it’s also easier for them coding an apphost which only has to look into one folder. Instead of hard coding names I would just prefer the initial mentioned solution of a project file customization:

<runtimeFilesPath>\runtime</runtimeFilesPath>
<referencedFilesPath>\references</referencedFilesPath>
<!-- Native files, images, text files etc !-->
<otherFilesPath>\bin</otherFilesPath>

On build this could be added to the json file the apphost is using. Sadly there are too many workarounds for making it a serious issue. There is the trimming feature reducing the file mess. There is publishing as single file. There are unofficial solutions like the apphost patcher doing exactly what most people her want. On top of that not too many upvotes. I believe we will sit on this for a very long time.

.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…

I wonder why self containing does not place local projects in with the apphost exe by default when self contained, the .NET Runtimes in a runtime/[runtime pack name]/ subfolder, and downloaded nuget packages which are depdenencies of all of those projects under packages/ to clean up the folders in self contained deployments and also make them easier to manually copy, package in a zip file, or even delete them.

If you are trying to simplify the output of your application, have you looked at the single executable option?

I’ve considered it, but a 60 MB release isn’t acceptable compared to something that should be less than 1 MB. The issue is the noise as more nuGet packages are added. They’re tiny in size, but add huge numbers of extra files that really don’t need to be polluting the root directory.

What about dnSpy HostPatcher?

Just read me post, I was pretty damn clear I think. Or just try it out yourself, only takes a couple of minutes. But stop this off topic discussion because people here subscribed and gets notification on each comment. And this topic is not about NetCoreBeauty or host patcher, they are just mentioned as a workaround you can try and see if it meets your needs. Original OP requested an inbuilt solution and people subscribed expect getting updates on an inbuilt solution. Thanks in advance for your understanding.

@vitek-karas Hello, I’ve been browsing through several of these similar issues and don’t see any recent updates. Has this issue been addressed at all in .Net 5?

I am also in a scenario where I have a large number of dll references but single-file is not an option. Essentially, I have a project with a large amount of shared business logic and multiple front-ends. If I use the standard verbose deployment, the separate interfaces can all share the same dlls (which saves space). If I use single-file, then each interface gets its own embedded copy of the shared code, which balloons the install size