Sdk: Why aren't reference assemblies resolved from the GAC when running on full .NET Framework?

[stajs]

I have a self-hosted (in a Windows Service) ASP.NET Core website running on full .NET Framework 4.6.1. When it is published and deployed to a machine that doesn't have the reference assemblies (i.e. C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1 doesn't exist) the website responds with:

InvalidOperationException: Can not find reference assembly '.NETFramework/v4.6.1/Microsoft.CSharp.dll' file for package Microsoft.CSharp

My understanding is that these reference assemblies are only for design-time/compile-time support and are installed by tooling (SDKs/Visual Studio) and not by the .NET Framework itself. The publish target has .NET Framework 4.6.1 but doesn't have the reference assemblies. If I copy the reference assemblies from my development machine to the publish target, everything works.

Is this a bug? Shouldn't it be trying to resolve the assembly from the GAC?

[stajs]

I am unblocked now, so feel free to close this if it is a distraction. I've left it open because I am still curious.

---

The Website project.json already had this:

"buildOptions": {
    "preserveCompilationContext": true,
}

Without it, view compilation fails with:

An error occurred during the compilation of a resource required to process this request. Please review the following specific error details and modify your source code appropriately.

Adding preserveCompilationContext to the Windows Service project.json as well, now gives me a refs folder in the publish output which includes Microsoft.CSharp.dll and everything is happy.

This seems buggy to me: when you are running full .NET Framework I feel that the refs folder shouldn't be needed; it should just resolve from the GAC.

[svick]

I could be wrong, but I think that the reason why you need reference assemblies is that ASP.NET Core uses Roslyn to compile views, and Roslyn requires reference assemblies even for .Net Framework. GAC contains runtime assemblies, so that does not help.

Using "preserveCompilationContext": true is the right fix.

[stajs]

Interesting.

I would still characterize the behavior as unexpected; if I target the full .NET Framework I expected it to run on a machine that "only" had it installed.

[TheRealPiotrP]

@svick is right. Compilation requires reference assemblies and those do not reside in the GAC. While a convenience in some cases, GAC dependencies lead to fragile builds because it's impossible to determine the specific versions of your dependencies that reside in a GAC on a given machine. By preserving the compilation context in its current form we're able to better protect against it works on my machine, but fails on that machine issues.

[stajs]

Thanks for the official word!

[allanFunrock]

Old issue but i stumbled upon it and had the same problem with the new project system and asp.net core running on Net47

Adding the property <BuildForIIS>true</BuildForIIS> to the project resolved the issue for me. Not having this, the refs folder got deleted during build

[EtharAlali]

Allan, thanks for this tip. Given the structure of the new VS2017 .NET CSProj files, where in the project file tree should the <BuildForIIS>true</BuildForIIS> go?

[aL3891]

It can go in any top level property group, for example:

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <BuildForIIS>true</BuildForIIS>
  </PropertyGroup>
...

(it doesn't have to have its own group though)

[donnyv]

I noticed if you have the Views folder included with the compiled View.dll when you start your IIS pool, you get this error. I was doing this on purpose for a short term work around hack.