runtime: Cannot resolve assembly paths for reference compilation libraries

Here’s a couple other workarounds for 2.0.0 until we have a resolution:

• If your application does not have any views, add <MvcRazorCompileOnPublish>false</MvcRazorCompileOnPublish> to disable Razor view compilation.
• If your application does have views, you can replace the default MetadataReferenceFeatureProvider to not throw when it encounters dll references:

using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;
using System.Reflection.PortableExecutable;
using Microsoft.AspNetCore.Mvc.ApplicationParts;
using Microsoft.CodeAnalysis;
using Microsoft.Extensions.DependencyModel;

namespace Microsoft.AspNetCore.Mvc.Razor.Compilation
{
    public class ReferencesMetadataReferenceFeatureProvider : IApplicationFeatureProvider<MetadataReferenceFeature>
    {
        public void PopulateFeature(IEnumerable<ApplicationPart> parts, MetadataReferenceFeature feature)
        {
            var libraryPaths = new HashSet<string>(StringComparer.OrdinalIgnoreCase);
            foreach (var assemblyPart in parts.OfType<AssemblyPart>())
            {
                var dependencyContext = DependencyContext.Load(assemblyPart.Assembly);
                if (dependencyContext != null)
                {
                    foreach (var library in dependencyContext.CompileLibraries)
                    {
                        if (string.Equals("reference", library.Type, StringComparison.OrdinalIgnoreCase))
                        {
                            foreach (var libraryAssembly in library.Assemblies)
                            {
                              libraryPaths.Add(Path.Combine(AppDomain.CurrentDomain.BaseDirectory, libraryAssembly));
                            }
                        }
                        else
                        {
                            foreach (var path in library.ResolveReferencePaths())
                            {
                                libraryPaths.Add(path);
                            }
                        }
                    }
                }
                else
                {
                    libraryPaths.Add(assemblyPart.Assembly.Location);
                }
            }

            foreach (var path in libraryPaths)
            {
                feature.MetadataReferences.Add(CreateMetadataReference(path));
            }
        }

        private static MetadataReference CreateMetadataReference(string path)
        {
            using (var stream = File.OpenRead(path))
            {
                var moduleMetadata = ModuleMetadata.CreateFromStream(stream, PEStreamOptions.PrefetchMetadata);
                var assemblyMetadata = AssemblyMetadata.Create(moduleMetadata);

                return assemblyMetadata.GetReference(filePath: path);
            }
        }
    }
}

And in your Startup:

services.AddMvc()
    .ConfigureApplicationPartManager(manager =>
    {
        var oldMetadataReferenceFeatureProvider = manager.FeatureProviders.First(f => f is MetadataReferenceFeatureProvider);
        manager.FeatureProviders.Remove(oldMetadataReferenceFeatureProvider);
        manager.FeatureProviders.Add(new ReferencesMetadataReferenceFeatureProvider());
    });

In my case, Razor compilation was fixed by installing of "Microsoft.Extensions.DependencyModel" Version="2.0.3". Thanks.

This was merged and should be fixed in 2.0.1

I ran into this issue with .NET Core 2.1.1. I was using the RazorLight lib coupled with some cshtml files for FluentEmail. Having the cshtml email templates in my project triggered error “Cannot find compilation library location for package” after deployment. I truly did not need the Razor compilation, since it was being handled by RazorLight at runtime, so adding <MvcRazorCompileOnPublish>false</MvcRazorCompileOnPublish> to the csproj resolved the issue

confirm it’s fixed with 2.0.3 November release, thanks

@ganeshmuthuvelu - I assume when you reference 2.0.2 above, you are talking about the .NET Core SDK version, correct?

Unfortunately, a new .NET Core SDK doesn’t fix this issue. The issue is in the Microsoft.Extensions.DependencyModel library, which ships when a new .NET Core Runtime ships, which should be coming soon.

Is this still a known issue and being worked on for a proper core update release?

Yes, the fix is in the release/2.0.0 servicing branch now, but we haven’t shipped a release since the fix was merged. The next 2.0.x release will have this fixed.

@tuespetre Thank you very much, it’s worked.

@tuespetre what you mean " put new MvcConfiguration().ConfigureMvc(mvcBuilder); in your ConfigureServices."? where is mvcBuilder from?

Is there a way to tell Razor compilation where to look for assemblies, or to ignore certain assemblies?

After upgrading to 2.0 i suffered for a long day until this hack by @pranavkm “worked the issue around” for me. My first shock was that PreserveCompilationContext came enabled by default, it caused severe problems with non-nuget assemblies that were added as path reference and Cefsharp.Core (most aren’t even used by cshtml views). I read somewhere about razor reference paths, but was unable to correctly configure that. When I disabled PreserveCompilationContext, then it started asking for manual input of the referenced assemblies, which for me would be okay, i was able to add assemblies with IRazorOptions.CompilationCallback, except for netstandard 2.0.0, which I couldn’t find a way to fetch with reflection (my project uses net462, Razor insisted that class “Object” is in netstandard, not mscorlib. I could get mscorlib file location at runtime, but not netstandard) By returning PreserveCompilationContext to true and using @pranavkm’s hack, it worked. Maybe razor compilation shouldn’t be so alarmful by default, maybe expose more ways to configure razor compilation: A way to tell razor to ignore dependency errors, a way to tell razor to ignore assemblies, a way to tell razor where to look for assemblies.

Possible fix for 2.01 is to add new resolver to Microsoft.Extensions.DependencyModel\Resolution that understands CompilationLibrary

Assigning to @eerhardt ; he will be able to evaluate this next week