Visual Studio 不断用旧版本覆盖 NewtonSoft.Json.DLL答案

【问题标题】：Visual Studio keeps overwriting NewtonSoft.Json.DLL with an older versionVisual Studio 不断用旧版本覆盖 NewtonSoft.Json.DLL
【发布时间】：2014-03-18 21:01:12
【问题描述】：

当我构建除包含该引用的网站之外的任何其他项目时，Visual Studio 正在用旧版本覆盖我在项目引用和 NuGet 包文件中配置的正确版本的 NewtonSoft.Json.DLL。

好的。这是场景：

我有一个包含后端服务和网站的解决方案。该网站在 .NET 4.5 上运行，并使用 NuGet 进行配置以引入 Newtonsoft.Json.DLL 的 6.0.1 版本。

<package id="Newtonsoft.Json" version="6.0.1" targetFramework="net45" />

这会将dependenAssembly 绑定添加到web.config 文件中。

  <dependentAssembly>
    <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" />
  </dependentAssembly>

我可以毫无问题地构建和运行这个网站。

我最近将所有类库和后端服务从 .NET 4.0 更新到 .NET 4.5。更新后，每当我构建其中一个类库或运行/调试后端服务时，网站就会无法运行。

Could not load file or assembly 'Newtonsoft.Json' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

我发现这是因为在重建其中一个类库或从 Visual Studio 运行/调试后端服务时，Newtonsoft.Json.DLL 会被旧版本的文件（4.5.11 版）覆盖。由于显式的dependentAssembly 绑定，之后我每次访问该网站时都会收到上面提到的“无法加载...”错误。

如果我只想运行后端服务或网站中的一个或另一个，这没问题，但我必须同时运行它们才能让我的应用程序正常运行。但是由于这个错误，我不能让后端服务在网站或网站崩溃的同时运行。

如何防止 Visual Studio 覆盖 DLL？

请注意，我在整个解决方案中只为 6.0.1 设置了参考（即没有参考 任何地方 到 4.5.11）。在网站中，我将 Newtonsoft.Json.DLL 的“本地复制”设置为 true，并且“特定版本”也设置为 true。

【问题讨论】：

我建议您为构建启用详细日志记录并跟踪 dll 的“错误”版本的确切来源。
完全一样的问题！在 NUGET 更新 OWIN、IDENTITY 和 EF 之后，我发现自己处于这种情况。在正确构建一个项目的同时，VS2013 将旧版本的 Newtonsoft.Json 放到其他项目中，旧版本与 GAC 中的相同。

标签： c# visual-studio-2012 dll visual-studio-2013 .net-4.5

【解决方案1】：

这是 Windows Azure VS 工具中的known bug

解决方法：

从 Program Files\Microsoft 中删除 Newtonsoft.Json.dll 文件 SDKs\Windows Azure.NET SDK\v2.3\ref\ 文件夹。
卸载 Windows Azure VS Tools v 2.3

【讨论】：

与 v2.8 相同的问题。我不得不重命名文件夹 C:\Program Files\Microsoft SDKs\Azure\.NET SDK\v2.8\bin\plugins\Diagnostics 中的 DLL
对于 2.9，dll 位于 \Program Files\Microsoft SDKs\Azure\.NET SDK\v2.9\ToolsRef。
与 v2.9 有同样的问题，这个文件 C:\Program Files\Microsoft SDKs\Azure\.NET SDK\v2.9\bin\plugins\Diagnostics\Newtonsoft.Json.dll
您的“已知错误”链接现在已损坏：（您有该错误的某种 ID 吗？
链接中的 @JohnDyer 票证 ID 为 850425，标题为“windows azure vs tools 破坏 web 项目的 msbuild”。微软重组连接网站后，我再也找不到这张票了。

【解决方案2】：

问题

您的 csproj 包含指向 Newtonsoft.Json dll 路径无效的引用。就我而言，它是

<HintPath>..\..\packages\Newtonsoft.Json\lib\net45\Newtonsoft.Json.dll</HintPath>

而不是 NuGet 应该设置的一个，packages\Newtonsoft.Json.8.0.3\... （包括版本号）。

由于 VS 找不到 dll，它只会在您的系统上搜索，并使用它找到的第一个。在我的系统上，那是 Azure SDK 2.9，然后是 Azure SDK 2.8，然后是 VS12/Blend/....

解决方案

上面的一些解决方案（删除您在系统中找到的所有 Newtonsoft.Json.dll）可能会在短期内隐藏问题，但仅修复 csproj 以指向正确的 NuGet 提供的路径将真正解决问题。

即确保你的csproj中的HintPath与安装NuGet包的包路径相对应。

如果你有 bash，你可以使用

$ grep -r HintPath * | grep Newtonsoft

在解决方案的根目录中找到有问题的 csproj。

相关错误

如果您遇到此问题，使用 web.config 中的显式重定向启动您的 Asp.Net 站点可能会失败并出现异常页面，错误消息中包含以下文本：

日志：正在尝试下载新 URL newtonsoft json

警告：比较程序集名称导致不匹配：主要版本

即使某些项目引用了 Newtonsoft.Json 8.x 的 NuGet，VS 也会愉快地编译，然后用它在系统上找到的旧 DLL 覆盖该 DLL，并在运行时失败。

【讨论】：

我怀疑这是否是解决方案，因为我使用 NuGet 来管理我的引用，并且其他项目工作正常。但是当我在文本编辑器中打开项目的 .csproj 时，果然有对 JSON.net 的正确引用，然后在下面的单独中，引用了旧 5.x 版本的 DLL失踪。通过 VS2015 GUI 删除引用并没有删除此引用。我不得不使用文本编辑器。我重新编译，JSON.NET .DLL 终于是正确的版本了。
NuGet 为每个不同的 .NET 目标框架存储不同版本的 DLL。对我来说，我删除了旧的 .NET 目标目录，然后从我的 bin 目录中删除了该文件，问题就自行解决了。
如果你没有有bash和grep，你可以使用findstr /s /c:HintPath *.csproj | findstr /c:Newtonsoft。
这也解决了我的问题。就我而言，我有两个对 Newtonsoft.Json 的引用——一个有效，一个无效。我删除了无效的路径，一切都很好。
请注意，如果您引用的库引用 Newtonsoft.JSON，但您的项目没有明确引用任何版本，也会发生这种情况。 MSBuild 会对未解决的依赖项发出警告，然后在 SDK 中找到 6.0.8 并将其复制到您的 bin 文件夹中。

【解决方案3】：

这是我遇到的情况。
解决方案中的 3 个项目。项目 A 和 B 引用了 Newtonsoft.Json.DLL 6.0.3 和对项目 C 的解决方案引用。项目 C 没有任何明确引用 Newtonsoft.Json.DLL。
在构建解决方案时，它构建 C，然后构建 A 和 B - 将正确的 dll 放入 bin 中。但是当我只构建 C VS 将旧版本的 dll 放到 A 和 B 时。由于不存在显式引用或绑定重定向，它从 GAC 获取。此外，Building only A 将较旧的 dll 放入 B，因为它首先构建 C 将错误的版本放入 A 和 B，然后构建 A 放入正确的版本。

这是解决方案 - 将 Newtonsoft.Json.DLL 6.0.3 显式添加到项目 C

【讨论】：

我对此表示赞同，因为它有效，但我认为这更像是一种解决方法而不是解决方案。

【解决方案4】：

我们最近遇到了同样的问题。我们的解决方案会在我们的开发机器上编译并拥有正确的 DLL，但在我们的构建代理上，错误版本的 Newtonsoft.Json 会被丢弃在输出文件夹中。

投入大量时间后，我们发现这是由于有人在我们的构建代理上安装了比我们在本地安装的更新版本的 Azure SDK：2.9 而不是 2.5.1。

我们发现的解决方法是在解决方案的每个项目中包含 Newtonsoft.Json NuGet 包，即使该项目不需要引用。

【讨论】：

在深入了解我们的构建日志（启用详细的构建日志）后，我们从我们项目中的其他库中发现了 Newtonsoft.JSON 的“未解析引用”，这导致 MSBuild 从 SDK 中查找版本。添加显式版本引用解决了这个副本。

【解决方案5】：

我有完全相同的问题，并发现在 C:\Program Files\Microsoft SDKs\Windows Azure.NET SDK\v2.3\ref 我有 Newtonsoft.Json.dll 与完全相同的日期和时间复制到我的网站文件夹中的那个。

重命名/删除 C:\Program Files\Microsoft SDKs\Windows Azure.NET SDK\v2.3\ref 中的 Newtonsoft.Json.dll 后，Visual Studio 停止替换我引用的版本，网站重新开始工作.

【讨论】：

搜索具有完全相同日期的 dll 对我有用。 C:\Program Files\dotnet\sdk\NuGetFallbackFolder\newtonsoft.json\11.0.2\lib\net45 实际上包含 10.0.3 dll

【解决方案6】：

我的情况几乎完全相同，只是我的 Newtonsoft.JSON DLL 是从不同位置复制的。我验证了我的解决方案引用了正确的文件和版本，但是在 RUN VS 上将其从另一个位置复制（首先通过将 BIN DLL 拖到 VS 或属性中进行检查。

最后，在使用Fusion logs 逐一尝试后，我全力以赴替换程序文件中具有相同错误版本的 Newtonsoft.JSON.dll 的所有引用：

'C:\Program Files (x86)\Microsoft SDKs\Microsoft Azure\Mobile 服务\1.0'
'C:\Program Files\Common Files\Microsoft Shared\Visual 工作室\12.0'
'C:\Program Files (x86)\Microsoft Visual Studio 12.0\混合'
等

快速提示：在资源管理器中的详细信息视图下添加“产品版本”作为列并按其排序：

如果我为该程序集设置 Specific Version 并且文件路径是正确的 DLL（由 NuGet 设置），它仍然感觉像是糟糕的 IDE 行为，它真的不应该用一个来覆盖它从另一个共享全球位置。任何在这里更改 Visual Studio 构建行为的 cmets 都将不胜感激，因为我真的不想在每台开发人员机器上进行这种类型的手动 hack。

【讨论】：

使用 NuGet 和更改软件包版本时要记住的事项：a) 让 NuGet 进行版本更改（不要卸载软件包版本来安装新版本，选择新版本，它将更新旧版本）b）让 NuGet 解决依赖关系（尝试在最高级别更新，即解决方案和父包）只有在这不起作用时才更新依赖包版本。如果您执行上述操作并更新 bindingRedirect（即对于 oldVersion="0.0.0.0" 的所有版本，请使用 newVersion="7.0.0.1"），那么只会保留例外。

【解决方案7】：

我今天遇到了同样的问题。我发现在构建类库之后，该类库的输出目录中的所有 *.dll 文件都被复制到具有对该类库的项目引用的任何 Web 项目的 bin 文件夹中。这可能导致兼容的程序集被不兼容的程序集替换。然而，这个 dll xcopy 不会在 web 项目被卸载时发生（右键单击项目并选择“Unload Project”）。

【讨论】：

【解决方案8】：

我有同样的问题，在测试了所有解决方案后，我仍然遇到错误。似乎是由于多种原因可能会发生此错误。

在我使用 VS 2015 的情况下，问题是对我的应用程序中使用旧版本 newtonSoft 的其他项目的未使用引用。我删除了引用，并且 dll 不再更改。

【讨论】：

【解决方案9】：

我遇到了同样的问题。

我已经用 nuget 安装了 newtonsoft 11.0 版本。

在构建或发布解决方案后，bin 文件夹中的 newtonsoft 引用被覆盖为 6.0 版本，并且发布的页面 dll 具有相同的 6.0 版本。一切都很好（package.config、调试、发布引用）。

经过大量跟踪找到适合我的解决方案。

所以尝试了以下。

重命名了以下位置的诊断文件夹中的 newtonsoft.dll 文件 Program Files\Microsoft SDKs\Azure.NET SDK\v2.8\bin\plugins\Diagnostics

它开始按预期工作。

【讨论】：