asp.net - 自 MS14-059 以来，System.Web.MVC 未复制到 bin 文件夹中。如何防止由于 Windows 更新而创建缺少 DLL 的构建？

Question

今天早上，据报道我们 QA 服务器上的 Web 应用完全崩溃，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

记得看到一个提到 MVC 的 Windows 更新，我做了一些挖掘并找到了 lots of people reporting最近的 Windows 更新破坏了 MVC。

在对这些问题和我们的服务器进行了大量挖掘之后，我们发现的问题似乎与其他问题中的内容不匹配，但看起来确实相关。这是我们认为知道的:

• 我们损坏的应用程序使用 ASP.NET MVC 5.1
• MVC 是通过 NuGet 安装的
• 我们的 BuildServer 和 QA 服务器没有安装 MVC 5.1(因此，没有 GAC)

我们认为损坏的部分导致创建了“错误的构建”:

• 通过 Windows Update 在 BuildServer 上安装了 MVC 5.1 的补丁尽管 GAC 中没有安装 MVC 5.1
• 补丁已将 MVC 5.1 的“更新”版本放入 GAC
• 当 DLL 在 GAC 中时，CopyLocal=true 被忽略；因此，自打补丁以来，这意味着我们从 BuildServer 构建的应用在输出文件夹中不再有 System.Web.MVC
• 由于 System.Web.MVC 不在我们 QA 服务器的 GAC 中(它们尚未打补丁)，应用程序现在失败，因为找不到 System.Web.MVC

假设上述行为是正确的，这意味着任何时候 MS 通过 Windows 更新服务 NuGet DLL 我们在 GAC 中没有，我们的 BuildServer 将开始生成不完整的构建(遗漏那些已注入(inject) GAC 的 DLL)。

升级到 MVC 5.2 解决了这个问题(可能是因为它没有打补丁，因此没有注入(inject) GAC)； DLL 现在被复制到输出文件夹。除了版本号更改外，升级到 5.2.2 的差异没有任何变化(特别是没有添加/编辑 <Private> 节点)。

我们不希望开始对所有内容进行 GAC，也不希望创建手动构建步骤来将我们所有的 DLL 复制到 bin文件夹以防 MS 修补它们。

那么，今天我们可以改变什么，以确保如果 MS 将来修补其他 DLL，我们永远不会让 BuildServer 默默地生成错误的构建？

Answer 1

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

是的，这种行为实际上是设计使然。参见 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

是的，没错；这就是补丁如何让更新的代码运行而不是旧代码。参见 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

不完全是。实际发生的是以前 CopyLocal=true 的项目切换到 CopyLocal=false。 CopyLocal 可以通过以下两种方式之一设置:1) 如果有明确的 <Private>True</Private>在 .csproj 文件中设置，或 2) 默认情况下，如果不存在此类设置(默认情况下，GAC 程序集不 CopyLocal；其他程序集执行)。

所以在这种情况下似乎发生的是您的项目文件在 csproj 文件中没有此设置。结果，GUI 显示了基于补丁前评估默认值的设置 (CopyLocal = true)，但在安装补丁后，GUI 现在将显示 GAC 程序集的新默认值 (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

没错。

---

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).

对于没有显式 <Private>True</Private> 的任何 .csproj 引用设定，没错。此外，请注意使用 NuGet 更新 MVC 引用可以删除此设置，即使它以前存在也是如此。参见 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).

没错。由于 MVC 5.2 不是 GAC，即使没有明确的 <Private>True</Private>设置，此非 GAC 程序集的默认值将为 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?

你今天能做的最好的事情是:

1. 明确 <Private>True</Private> .csproj 文件中所有 NuGet 包程序集引用的设置。
2. 在修复 NuGet 错误 #4344 之前，任何时候您使用 NuGet 更新包引用时，请返回您的 .csproj 文件并重新添加显式 <Private>True</Private>设置。