msbuild: GAC Resolution fallback introduces unexpected bugs - should be an error instead of a warning

So this one could be fun, because I immediately realize it’s going to break some people if implemented. I’m here to argue that’s a good thing. This was brought up by an issue we hit while upgrading to .Net 4.6. But, it’s far from the first time I’ve been bitten by it.

MSBuild currently falls back to the framework assemblies in the GAC if the targeted framework reference assemblies are not on the machine. You get a warning like this:

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets(983, 5): warning MSB3644: The reference assemblies for framework “.NETFramework,Version=v4.5.2” were not found. To resolve this, install the SDK or Targeting Pack for this framework version or retarget your application to a version of the framework for which you have the SDK or Targeting Pack installed. Note that assemblies will be resolved from the Global Assembly Cache (GAC) and will be used in place of reference assemblies. Therefore your assembly may not be correctly targeted for the framework you intend.

That’s a warning, not an error - the build continues. I’m arguing this should break the build, not produce downstream unexpected results.

Here’s the relevant code where the MSBuild decision of “can’t find the target? let’s use the GAC instead”, in GetPaths() is made. The GAC fallback seems explicitly intentional, as described here - but I think that’s bad behavior, especially with the framework core libraries.

The comment in code notes this:

// No reference assembly paths could be found, log a warning as there could be future errors which may be confusing because of this.

An example is the one we hit, there Array.Empty<T> was used in a Roslyn compiler optimization. Roslyn acted correctly here because it was passed a set of .Net 4.6 assemblies (via the GAC path) on our build server - even though MSBuild was told we were targeting Net 4.5.2. The “helpful” fallback really wasn’t - it led to downstream runtime breaks.

Semi-related: .Net 4.5.2 is curiously absent from MSBuild altogether: it doesn’t have the paths for .Net 4.5.2 cached, and I noticed 4.5.2 isn’t in the TargetDotNetFrameworkVersion enum either. I assume that’s because it has no compile-time relevance between 4.5.1 and 4.6, but I thought I would note it here for completeness sake.

In my experience (granted, I may have a slanted view), this fallback behavior usually results in a forward fallback, to a newer version of the framework than reference assemblies are installed for and targeting specified. This brings in assumptions of framework features for compilers and tools to make use of that won’t be present at runtime.

If anything, assumptions should be made to older versions of the framework than targeted, since those would be far more likely to be successful. But, I don’t think MSBuild should do that either. I think it should break the build, with a helpful error message saying where to get and install the reference assemblies. MSBuild already knows where it tried to find the assembly path for that framework moniker, it should relay this information to the user. Note: the existing error message doesn’t provide this info either.

What happens today is a range of not loading to slightly different behavior to runtime errors to just crashing the application. That’s much worse (in my opinion) than breaking the build and telling the user how to fix it.

From another view: MSBuild isn’t compiling what I asked it to. It’s subbing in assemblies and causing problems down the line, possibly in the hands of customers.

So here it is: How about we make failure to find the targeted framework reference assemblies break the build instead of just a warning and silently not compiling what was asked for?