Support loading ASP.NET Core into non-default load contexts

[rynowak]

Describe the solution you'd like

Users creating a module system that uses ASP.NET Core will run into problems if they are using a non-default AssemblyLoadContext. The reason is that we have various features that operate outside of a load context, usually by using LoadFile instead of one of the more context-aware methods.

Known features that don't support ALCs:

• Loading related application parts (views/pages)
• (possibly more)

Additional context

While we haven't totally ignored this as an area, it's not something we document and test. At a minimum completing this would would require identifying a few scenarios that are good as samples and documenting them. We have not done a full effort to ensure that ever part of ASP.NET Core will work in this mode.

Original source: filing a feature request based on a support ticket for an unsupported scenario.

[davidfowl]

The good news is, using Assembly.Load is good using Assembly.LoadFrom/LoadFile isn't so good. We only have one place that does this in the product today so we're in pretty good shape so far.

[vitek-karas]

Depending on what the overall feature should be Assembly.Load may be problematic as well.

Currently runtime doesn't support loading frameworks into isolated ALCs, so the typical use case is actually loading ASP.NET itself into default ALC (since it's a framework) and loading the app into a secondary ALC. This has been asked for several times, recently for example here: dotnet/runtime#37584. Scenarios I know of are for example:

• Running multiple smaller apps in one process to save resources
• Ability to reload an app without restarting process

In such case even Assembly.Load doesn't work well. It uses the ALC of the immediate caller, which is ASP.NET which lives in default ALC. So it will load whatever assembly it wants into the default ALC - even if the app was started from a secondary ALC.

It might be possible to workaround this by using AssemblyLoadContext.CurrentContextualReflectionContext which tells Assembly.Load which ALC to use. This would obviously need testing.

Also note that similar issues to Assembly.Load are with many other reflection APIs, like Type.GetType - see https://github.com/dotnet/coreclr/blob/master/Documentation/design-docs/AssemblyLoadContext.ContextualReflection.md#currently-affected-apis for the full list.

Ability to load ASP.NET itself into a secondary ALC is more complex. Not only it would likely require testing and other work on the ASP.NET side, but it's actually a rather non-trivial runtime feature. It's also unclear if this is the actual intent (Do we expect customers to run different versions of the ASP.NET framework inside one process?).

Yet another issue is unloadability - to correctly support the ability to reload an app without restarting the process not only the app has to run in a secondary ALC, but such ALC must be able to unload. Currently there are several issues in the core framework (Microsoft.NETCore.App) around this where different types of caches hold on to things regardless of ALCs (for example caches in TypeConverter - dotnet/runtime#30656). Similarly on ASP.NET side there's a discussion about it here: #21744.

[ghost]

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[JunTaoLuo]

Sounds like this issue will need investigation. Potentially for the next release.

[JunTaoLuo]

@Pilchie looks like we might need someone to investigate what we want to do here, potentially for 6.0. Is there a higher level initiative to modules support across dotnet?

[davidfowl]

We have a bunch of these issues around what happens when you try to use various parts of ASP.NET Core with AssemblyLoadContext. The goal is to spend some time understanding those scenarios so that we can make a better judgement call as to whether we want to do something about them.

Here's another example of an issue that came up with ALC in MVC #21744

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.