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.