How to get a complete isolation of a user-created AssemlyLoadContext?

[msedi]

Coming from here #69899.

Currently the AssemblyLoadContext (ALC) has no complete isolation from the default ALC. In detail, if you have static fields in your default ALC (e.g. logging), the user-created ALC "inherits" already existing static fields.

The get around this you have to load the assembly that contains the static field explicitly in the user-created ALC . The problem is that it is mostly unknown which assemblies have static fields and one has to find out until every assembly needs to be loaded until it works.

As far as I remember AppDomains provided a better isolation. So my question is if there is a way to completely isolate the user-created ALC and to force the ALC to not "inherit" already loaded assemblies, but to really isolate the user-created ALC such that all required assemblies are loaded into the user-created ALC?

[jkotas]

So my question is if there is a way to completely isolate the user-created ALC and to force the ALC to not "inherit" already loaded assemblies, but to really isolate the user-created ALC such that all required assemblies are loaded into the user-created ALC?

The only way to achieve non-cooperative isolation like this is to run in a separate process.

[jkotas]

But it seems visual studio is not able to handle this correctly and when the process is closed or dies, VS has troubles managing the debugging.

It sounds like a bug in Visual Studio. It would great if you can report it through https://developercommunity.visualstudio.com/home

I'm not sure, did AppDomains provided a better way of isolation?

Yes, the AppDomains tried to create multiple processes in a single physical process. It was very complicated and not very efficient.

[huoyaoyuan]

I remember that even with AppDomains, one physical process can only have one corelib due to close interop with CLR.

[jkotas]

Yes, .NET Framework required the same CoreLib to be used by all AppDomains. Each AppDomains still had its own copy of CoreLib statics. It made static access much slower. The statics access required finding the current thread appdomain and finding the address of that static in the current appdomain.

[msedi]

@jkotas: Thanks for the info. As you said,

It sounds like a bug in Visual Studio. It would great if you can report it through https://developercommunity.visualstudio.com/home

I have reported a few bugs around the debugger, but it seems no one has interest and the tickets were closed.
So I have doubts that this will ever be solved (maybe it is too much of a niche). There are maybe not to many developers out there that need to attach the debugger programmtically and from I can see this is not something really supported by the VS:
https://stackoverflow.com/questions/11811856/attach-debugger-in-c-sharp-to-another-process.

In the meantime I would use the ALC for debugging purposes. Otherwise debugging is a nightmare. The question is if there is a possiblity to force all related assemblies to be loaded into the ALC, or if I have to do it myself, be recursing through the related assemblies or if the is a better approach?

[jkotas]

Take a look at AssemblyDependencyResolver and this sample: https://learn.microsoft.com/en-us/dotnet/core/tutorials/creating-app-with-plugin-support#load-plugins