Compiled Razor views loaded in default ALC instead of current ALC

[gokarnm]

MVC Razor does not work correctly if the Razor compilation engine is run inside a custom AssemblyLoadContext (ALC). The dynamically compiled Razor view assemblies cannot find their dependencies as they are loaded in the default ALC (AssemblyLoadContext.Default) instead of the "current" ALC. This seems like a bug.

Here is a partial stack trace

System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.AspNetCore.Mvc.Razor, Version=1.0.1.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'. The system cannot find the file specified.

File name: 'Microsoft.AspNetCore.Mvc.Razor, Version=1.0.1.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'
   at System.Reflection.RuntimeAssembly.GetExportedTypes(RuntimeAssembly assembly, ObjectHandleOnStack retTypes)
   at System.Reflection.RuntimeAssembly.GetExportedTypes()
   at Microsoft.AspNetCore.Mvc.Razor.Internal.DefaultRoslynCompilationService.Compile(RelativeFileInfo fileInfo, String compilationContent)
   at Microsoft.AspNetCore.Mvc.Razor.Internal.CompilerCache.CreateCacheEntry(String relativePath, String normalizedPath, Func`2 compile)
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNetCore.Mvc.Razor.Internal.CompilerCache.GetOrAdd(String relativePath, Func`2 compile)
   at Microsoft.AspNetCore.Mvc.Razor.Internal.DefaultRazorPageFactoryProvider.CreateFactory(String relativePath)
   at Microsoft.AspNetCore.Mvc.Razor.RazorViewEngine.CreateCacheResult(HashSet`1 expirationTokens, String relativePath, Boolean isMainPage)
   at Microsoft.AspNetCore.Mvc.Razor.RazorViewEngine.OnCacheMiss(ViewLocationExpanderContext expanderContext, ViewLocationCacheKey cacheKey)
   at Microsoft.AspNetCore.Mvc.Razor.RazorViewEngine.LocatePageFromViewLocations(ActionContext actionContext, String pageName, Boolean isMainPage)
   at Microsoft.AspNetCore.Mvc.Razor.RazorViewEngine.FindView(ActionContext context, String viewName, Boolean isMainPage)
   at Microsoft.AspNetCore.Mvc.ViewEngines.CompositeViewEngine.FindView(ActionContext context, String viewName, Boolean isMainPage)
   at Microsoft.AspNetCore.Mvc.ViewFeatures.Internal.ViewResultExecutor.FindView(ActionContext actionContext, ViewResult viewResult)
   at Microsoft.AspNetCore.Mvc.ViewResult.<ExecuteResultAsync>d__26.MoveNext()

I was able to get past the issue by modifying the code in DefaultRoslynCompilationService L195 from

System.Runtime.Loader.AssemblyLoadContext.Default.LoadFromStream(assemblyStream, pdbStream);

to the following, so that we use the current ALC instead.

var currentAlc = AssemblyLoadContext.GetLoadContext(
    typeof(DefaultRoslynCompilationService).GetTypeInfo().Assembly);
currentAlc.LoadFromStream(assemblyStream, pdbStream);

I noticed that the ViewsFeatureProvider class also does the same, where it loads into default instead of current ALC.

[davidfowl]

Out of curiosity, how did you run into this?

[gokarnm]

Hi @davidfowl, I have a host application that loads one or more plugins. Each plugin is loaded from a different base directory that contains the plugin DLL and plugin deps.json file. Each plugin runs in a custom AssemblyLoadContext(ALC).

The MVC Razor engine is being run inside one of the plugins. I hit a couple of other issues detailed here https://github.com/dotnet/core-setup/issues/1739, before hitting this one.

[davidfowl]

@gokarnm Do you want to send a pull request to MVC for this? You'd also need to write a test to verify that view compilation works inside of a custom load context once you make this change.

/cc @pranavkm

[pranavkm]

The change would also need to go here - https://github.com/aspnet/Mvc/blob/dev/src/Microsoft.AspNetCore.Mvc.Razor/Compilation/ViewsFeatureProvider.cs#L74 - where we discover precompiled views.

[gokarnm]

Sounds great @davidfowl , I'll submit a PR.
@pranavkm , ya I did notice that one too, though I might have some questions when I write tests for it.

[rynowak]

We now use this Assembly.LoadFile API to load views, so this is moot.

[waxingsatirical]

We now use this Assembly.LoadFile API to load views

could this be why Razor is not playing well with Fody/Costura?

It works by including referenced assemblies ({MyProject}.View.dll) as embedded resources and then hooking into the AppDomain.CurrentDomain.AssemblyResolve event.