从Web.config中今天上午据报道，我们的我们的QA服务器上的Web应用程序是完全错误如下破报告：

  

无法加载文件或程序集System.Web.Mvc，版本= 5.1.0.0，文化=中性公钥= 31bf3856ad364e35或它的某一个依赖。该系统找不到指定的文件

缅怀看到一个Windows更新中提到MVC，我做了一些挖掘和发现lots of people reporting最近的Windows更新打破MVC。

在通过这些问题，并在我们的服务器多挖，似乎什么被咬我们不匹配什么在那些其他的问题，但它确实出现有关。以下是我们认为知道的：

在我们的应用程序，它坏了使用ASP.NET MVC 5.1 在MVC经的NuGet安装 我们BuildServer和质量保证服务器没有MVC 5.1安装（因此，并不GAC'd）

我们认为，打破导致坏构建要创建的：

系统补丁程序的MVC 5.1中尽管没有MVC 5.1安装在GAC 的安装在通过Windows Update的的BuildServer 在该补丁已经把更新版本的MVC 5.1在GAC CopyLocal =真被忽略时，DLL是在GAC;因此，由于该补丁，这意味着建立我们从BuildServer 不再有System.Web.MVC在输出文件夹 应用程序的 由于System.Web.MVC不是在GAC上我们的QA服务器（它们尚未被修补），应用程序现在将失败，因为System.Web.MVC无法找到

假设上述的行为是正确的，这意味着任何时候MS服务通过Windows Update的一个的NuGet DLL，我们没有在GAC 的都有，我们BuildServer将开始生产不完整的构建（错过了那些已被注入到GAC DLL）的

升级到MVC 5.2解决了这个问题（可能是因为它没有被修补，并因此不注入GAC）;该DLL现在被复制到输出文件夹。有迹象表明，升级到5.2.2，除了版本号变化差异没有改变（有具体地没有＆LT;私营＆GT; 节点添加/编辑）。

我们不希望启动GACing一切，也没有创造手工打造步骤，我们所有的DLL复制到斌文件夹，以防万一MS修补它们。

那么，我们该怎么改变的今天的，以确保我们永远不要结束与出BuildServer默默回生产构建不好，如果MS补丁其他DLL的未来？

解决方案        

一个补丁MVC 5.1中尽管没有MVC 5.1安装在通过Windows Update的BuildServer安装在GAC

  

是的，这种行为实际上是由设计。请参阅http://blogs.msdn.com/b/dotnet/archive/2014/01/22/net-4-5-1-supports-microsoft-security-updates-for-net-nuget-libraries.aspx.

       

该补丁已经把更新版本的MVC 5.1在GAC

  

是的，这是正确的;它是如何获得补丁更新code运行，而不是旧code。请参阅https://technet.microsoft.com/en-us/library/security/ms14-059.

       

CopyLocal =真当DLL是在GAC忽略;因此，由于该补丁，这意味着建立我们从BuildServer应用程序中不再有System.Web.MVC在输出文件夹

  

不完全是。什么实际情况是，previously被CopyLocal =真被切换为CopyLocal =假的项目。 CopyLocal可以通过以下两种方式之一进行设置：1）如果有一个明确的＆LT;私人和GT;真＆LT; /私募＆GT; 在.csproj的文件中设置，或2）在默认情况下如果没有这样的设置存在（GAC'd组件默认不CopyLocal;其他组件一样）

。

那么，什么似乎发生在这种情况下，你的项目文件并没有在的csproj文件此设置。其结果是，在GUI补丁之前显示基于所评估的缺省值的设置（CopyLocal =真），但是在安装补丁之后，GUI会现在表明为一个GAC'd装配新的默认值（CopyLocal =假）。

       

由于System.Web.MVC不是在GAC上我们的QA服务器（它们尚未被修补），应用程序现在将失败，因为System.Web.MVC无法找到

  

这是正确的。

       

假设上述的行为是正确的，这意味着任何时候MS服务通过Windows Update上的N​​uGet DLL，我们没有在GAC有，我们BuildServer将开始生产不完整的构建（错过了那些已被注入的DLL海关总署）。

  

对于没有明确任何的.csproj参考＆LT;私人和GT;真＆LT; /私募＆GT; 设置，这是正确的。此外，使用的NuGet更新您的MVC的参考可以删除即使它是previously present此设置注意。请参见 HTTP：//nuget.$c$cplex.com/workitem/4344

       

升级到MVC 5.2解决了这个问题（可能是因为它没有被修补，并因此不注入GAC）;该DLL现在被复制到输出文件夹。有迹象表明，升级到5.2.2，除了版本号变化差异没有变化（特别是有没有节点被添加/编辑的）。

  

这是正确的。由于MVC 5.2未GAC'd，即使没有明确的＆LT;私人和GT;真＆LT; /私募＆GT; 设置，这种非GAC'd组件的默认值将是CopyLocal =真。

       

我们不希望启动GACing一切，也没有创造手工打造步骤，我们所有的DLL复制到万一MS修补他们的bin文件夹。     那么，我们该怎么今天改变，以确保我们永远不要结束与出BuildServer默默回生产构建不好，如果MS补丁其他DLL的未来？

  

您今天可以做的最好的是：

将显＆LT;私人和GT;真＆LT; /私募＆gt;以您的所有的Nu​​Get包集引用您的.csproj文件设置 在此之前的NuGet的bug＃4344是固定的，你用的NuGet更新包的参考任何时候回到你的.csproj文件，并重新添加明确的＆LT;私人和GT;真＆LT; /私募＆GT; 设置。

This morning it was reported that our web app on our QA server was completely broken with the following error reported from Web.config:

Could not load file or assembly 'System.Web.Mvc, Version=5.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified

Remembering seeing a Windows Update that mentioned MVC, I did some digging and found lots of people reporting a recent Windows Update breaking MVC.

After much digging through those questions and our server, it seems that what's bitten us does not match what's in those other questions, but it does appear related. Here's what we think know:

Our app that is broken uses ASP.NET MVC 5.1 MVC was installed via NuGet Our BuildServer and QA servers do NOT have MVC 5.1 installed (therefore, not GAC'd)

What we believe has broken caused the "bad build" to be created:

A patch for MVC 5.1 was installed on the BuildServer via Windows Update despite not having MVC 5.1 installed in the GAC The patch has put the "updated" version of MVC 5.1 in the GAC CopyLocal=true is ignored when a DLL is in the GAC; therefore since the patch, this means that builds of our app from the BuildServer no longer have System.Web.MVC in the output folder Since System.Web.MVC is not in the GAC on our QA servers (they have not yet been patched), the application now fails, because System.Web.MVC cannot be found

Assuming the behavior described above is correct, this means that any time MS service a NuGet DLL via Windows Update that we do not have in the GAC, our BuildServer will start producing incomplete builds (missing out those DLLs that have been injected into the GAC).

Upgrading to MVC 5.2 solves this issue (likely because it wasn't patched, and was therefore not injected into the GAC); the DLL is now copied to the output folder. There are no changes in the diff that upgraded to 5.2.2 except for version number changes (there's specifically no <Private> node been added/edited).

We do not wish to start GACing everything, nor creating manual build steps to copy all of our DLLs into the bin folder just in case MS patches them.

So, what can we change today to ensure we don't ever end up with out BuildServer silently producing back bad builds if MS patch other DLLs in the future?

解决方案

A patch for MVC 5.1 was installed on the BuildServer via Windows Update despite not having MVC 5.1 installed in the GAC

Yes, this behavior is actually by design. See http://blogs.msdn.com/b/dotnet/archive/2014/01/22/net-4-5-1-supports-microsoft-security-updates-for-net-nuget-libraries.aspx.

The patch has put the "updated" version of MVC 5.1 in the GAC

Yes, that's correct; it's how the patch gets the updated code to run instead of the old code. See https://technet.microsoft.com/en-us/library/security/ms14-059.

CopyLocal=true is ignored when a DLL is in the GAC; therefore since the patch, this means that builds of our app from the BuildServer no longer have System.Web.MVC in the output folder

Not exactly. What actually happens is a project that previously was CopyLocal=true gets switched to CopyLocal=false. CopyLocal can be set in one of two ways: 1) If there's an explicit <Private>True</Private> setting in the .csproj file, or 2) By default, if no such setting exists (GAC'd assemblies do not CopyLocal by default; other assemblies do).

So what appears to have happened in this case is that your project file didn't have this setting in the csproj file. As a result, the GUI showed the setting based on the evaluated default value before the patch (CopyLocal = true) but then after the patch was installed, the GUI will now show the new default value for a GAC'd assembly (CopyLocal = false).

Since System.Web.MVC is not in the GAC on our QA servers (they have not yet been patched), the application now fails, because System.Web.MVC cannot be found

That's correct.

Assuming the behavior described above is correct, this means that any time MS service a NuGet DLL via Windows Update that we do not have in the GAC, our BuildServer will start producing incomplete builds (missing out those DLLs that have been injected into the GAC).

For any .csproj reference without an explicit <Private>True</Private> setting, that is correct. Also, note the using NuGet to update your MVC reference can remove this setting even if it was previously present. See http://nuget.codeplex.com/workitem/4344.

Upgrading to MVC 5.2 solves this issue (likely because it wasn't patched, and was therefore not injected into the GAC); the DLL is now copied to the output folder. There are no changes in the diff that upgraded to 5.2.2 except for version number changes (there's specifically no node been added/edited).

That's correct. Since MVC 5.2 is not GAC'd, even without an explicit <Private>True</Private> setting, the default value of this non-GAC'd assembly will be CopyLocal=true.

We do not wish to start GACing everything, nor creating manual build steps to copy all of our DLLs into the bin folder just in case MS patches them. So, what can we change today to ensure we don't ever end up with out BuildServer silently producing back bad builds if MS patch other DLLs in the future?

The best you can do today is:

Put explicit <Private>True</Private> settings in your .csproj file for all your NuGet package assembly references. Until NuGet bug #4344 is fixed, any time you use NuGet to update a package reference, go back into your .csproj file and re-add the explicit <Private>True</Private> setting.