Help! My build broke after Windows Updates!

On October 14th, 2014, Microsoft released several patches for ASP.NET. Three of these were for MVC, and they had some nasty side effects for the project I’m currently on. I will explain the three snags we hit with this update and how we solved them.

The updates in question are: 2993937 (MVC 3.0), 2993928 (MVC 4.0) and 2992080 (MVC 5.0).

MVC solution won’t compile anymore

This is the most obvious of the three. After installing the update, we got all sorts of compiler errors, like:

Could not locate the assembly "System.Web.Mvc,Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35,processorArchitecture=MSIL"

This error is sort of buried in all kinds of resulting errors:

The type or namespace name 'Controller' could not be found (are you missing a using directive or an assembly reference?)

Problem

The reason for this is that the updates replaced the System.Web.Mvc dlls in the GAC with a different version number. So, System.Web.Mvc 3.0.0.0 was replaced with 3.0.0.1, 4.0.0.0 was replaced with 4.0.0.1 and 5.0.0.0 was replaced with 5.0.0.1. This breaks your references if you happened to have them setup to look at the GAC.

Solution

We removed the System.Web.Mvc reference in our project and installed the NuGet package instead, as explained in this blog post. In our case, using MVC 4, we did this using the package manager console (be sure to select the correct project first):

Install-Package Microsoft.AspNet.Mvc -Version 4.0.40804.0

After this, the System.Web.Mvc dll is added to the project instead of referenced from the GAC, which should prevent such errors in the future if another update changes the version number again. You may want to check that the Copy Local flag for the System.Web.Mvc reference is set to true.

FxCop gives errors

The second problem occurred after we fixed our compile step. Our Code Analysis step would then mention that it could not find some MVC dll. However, it was looking for an MVC 3 dll, while we are using MVC 4. What gives?

8>MSBUILD : error : CA0058 : The referenced assembly 'System.Web.Mvc, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' could not be found. 
    This assembly is required for analysis and was referenced by: C:\Projects\FrontEnds.MyFE\bin\FrontEnds.MyFE.Implementation.dll

Problem

It turns out one of the libraries we use has a reference to MVC 3. As FxCop also looks at indirect references, this error was thrown to us. We do not particularly care about code analysis on indirect references, so we had to look for a way to turn this check off.

Solution

There is no easy to find way to turn this off. Since we use FxCop from MSBuild, not from the command line, we cannot use the command line parameter to do it. However, this blog post explains a way to do it. We added the following line to the .csproj file for the implementation project (right below the CodeAnalysisRuleSet element):

<CodeAnalysisAdditionalOptions>/assemblycomparemode:StrongNameIgnoringVersion</CodeAnalysisAdditionalOptions>

FxCop warning gone!

Errors after deployment to the web server

Now that our build was completely fixed, we went to install the application on our application server. However, we were soon greeted with the yellow screen of death. It turns out that three dlls could not be found: System.Net.Http.Formatting.dll, System.Web.Http.dll and System.Web.Http.WebHost.dll.

Problem

The reason this issue popped up after the updates is that these dlls were added to the GAC with the updates. Because the Copy Local property of these references was set to false, they were not copied with the build (MSBuild does not copy references to the output by default if they are present in the GAC). Before the update they were not in the GAC so they were copied.

Solution

There are two solutions to this. Obviously this error would not have occurred had we installed the updates on the application server as well. But because we were close to a release, we did not want to install updates without having tested them on our development servers first. So instead we went with the (in my opinion) safe route – we set Copy Local to true. This ensures that the dlls are copied to the solution’s bin folder, and also ensures that those dlls are always used, regardless of which version is in the GAC.

Conclusion

This was the first time we had a Windows Update cause this much trouble for our project. Next time we will be more prepared. However, this should not occur too often as version numbers on dlls do not generally change with Windows Updates.

Leave a Reply

Your email address will not be published. Required fields are marked *