Developers can create scopes to support load/unload scenarios because AssemblyLoadContext is supported throughout .NET

[samsp-msft]

The assembly load context has been rather successful in solving a large set of customer problems. The most prominent one is the so called “plugin” model where the application (host) loads other components to augment its functionality in some way. Such components are typically loaded into separate load contexts to avoid dependency collisions. Additionally, in some apps it’s also desirable to be able to eventually unload such components either to free resources or to enable update of the component.

Producing such applications has proven rather challenging in the current state of .NET Core because there are certain parts of the frameworks produces by us which are not compatible with multiple load contexts and/or unload ability.
We should drive the frameworks we own to fix these issues so that customer’s code doesn’t have to handle issues in frameworks they rely on. We should focus this effort on certain application types first to prioritize the work. We’ve seen feedback on mainly ASP.NET and WPF applications. There might be overlap with the “faster inner loop” effort which would affect the prioritization as well.

The work can be split into two parts (and prioritized differently):

• Given feature works correctly in presence of secondary load context – for example XamlParser has problems when used with assemblies in non-default load context. Similarly, ASP.NET’s hosting code also doesn’t work well in such a scenario. It might be possible to use static analyzers to detect some of the problems in this area.
• Usage of a given feature doesn’t prevent secondary load context from unloading correctly – for example TypeConverter holds onto all types which were used with it, and thus prevents unloading of such types. Static analyzers are probably not going to help in this area.

In both cases an important part of the work should be a general approach to testing – for example reuse existing test assets but run them under different conditions and providing customer guidance for first & third parties.

Work Items

• TBD

[Pilchie]

dotnet/aspnetcore#21159 is a related workitem.

[srxqds]

excited，thank you.
the monovm runtime is not full supported.
we hope you can keep more focus on it.
we are waiting for it everyday.
thank you.

[danmoseley]

@jeffschwMSFT this seems primarily runtime work. Is there a better epic to parent it under than the libraries one?

[jeffschwMSFT]

I don't have a strong feeling about where it would parent. It was in the theme of developer experience and hence why it ended up here. At this point there is no specific ask but once the dev inner loop work is settled it could become more important. So it could either become bottoms up or parent under dev inner loop.

[danmoseley]

@stephentoub when he's back can perhaps help clarify whether this is necessary for dev inner loop.

[govert]

I am loading the runtime and a managed assembly from native code using the hostfxr hosting interfaces. I find that my managed assembly is loaded into a new IsolatedComponentLoadContext as expected. I then create a new CustomAssemblyLoadContext of my own, into which further code is loaded. I can never unload the library that contains the initial managed entry point as it will be loaded into the IsolatedComponentLoadContext , and this type is not created as IsCollectible.

I want to suggest as part of this issue that the hostfxr gets some mechanism to make a collectible managed extension, loaded from the native host interfaces. (I am not trying to unload the runtime from the process, just my own native & managed libraries, for example to update and reload it.) Ideally, I want my (collectible) CustomAssemblyLoadContext to be instantiated as part of my initial managed code load, and then have some mechanism to (attempt to) unload this collectible ALC from the native hostfxr side.

I'm not quite there yet, but I think I would also like a way to know (from the native hostfxr side) when the unload attempt is complete, and whether it was successful. Maybe some callback would work for this.

Under the .NET Framework, such unloading works through the AppDomain support and ICorRuntimeHost->UnloadDomain(...)