使用多个项目时出现Newtonsoft.Json.dll问题

时间:2014-07-16 00:27:53

标签: asp.net asp.net-web-api visual-studio-2013 json.net nuget

我看到一些非常奇怪的行为,我无法纠正与Newtonsoft.Json.dll的引用相关。我有一个样本解决方案,其中包含以下项目:

  • JsonProblem.Core
  • JsonProblem.CauseProblem(引用JsonProblem.Core)
  • JsonProblem.Web(引用JsonProblem.Core和JsonProblem.CauseProblem)

在JsonProblem.Core和JsonProblem.Web中,我添加了“Microsoft ASP.NET Web API 2.2”NuGet包。在JsonProblem.Core中,我创建了一个web api。如果我构建JsonProblem.Core并从JsonProblem.Web运行一个页面,一切都按预期工作。

现在如果我构建JsonProblem.CauseProblem并尝试在JsonProblem.Web中查看页面,我会收到以下错误。

  

无法加载文件或程序集“Newtonsoft.Json”或其中一个   依赖。定位程序集的清单定义没有   匹配程序集引用。 (HRESULT异常:0x80131040)

如果我重建JsonProblem.Core,则错误消失。再次,如果我构建JsonProblem.CauseProblem后不构建JsonProblem.Core(即使JsonProblem.CauseProblem依赖于JsonProblem.Core)我得到错误。不知何故,JsonProblem.CauseProblem的构建导致Newtonsoft.Json版本4.5.11被复制到JsonProblem.Web bin目录,覆盖版本6.0.3。我很确定我正确设置了绑定重定向,因为我在JsonProblem.Web web.config和JsonProblem.Core和JsonProblem.CauseProblem的app.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>

所以我对这种奇怪行为的原因感到茫然。我在2个项目中复制了它。当我构建JsonProblem.CauseProblem时,似乎忽略了绑定重定向。我可以解决它,但我担心无论哪种错误或功能导致此行为可能会改变后台中可能导致问题的其他引用。


编辑 - 正如tizzy建议我使用fuslogvw工具。这是日志中生成的内容。但是,我不确定如何解释这个,因为日志并没有告诉我在构建时会发生什么情况来覆盖应用程序网站目录中的Newtonsoft.Json.dll版本。

The operation failed.
Bind result: hr = 0x80131040. No description available.

Assembly manager loaded from:  C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
Running under executable  C:\Program Files\IIS Express\iisexpress.exe
--- A detailed error log follows. 

=== Pre-bind state information ===
LOG: DisplayName = Newtonsoft.Json
 (Partial)
WRN: Partial binding information was supplied for an assembly:
WRN: Assembly Name: Newtonsoft.Json | Domain ID: 5
WRN: A partial bind occurs when only part of the assembly display name is provided.
WRN: This might result in the binder loading an incorrect assembly.
WRN: It is recommended to provide a fully specified textual identity for the assembly,
WRN: that consists of the simple name, version, culture, and public key token.
WRN: See whitepaper http://go.microsoft.com/fwlink/?LinkId=109270 for more information and common solutions to this issue.
LOG: Appbase = file:///C:/Users/John/Desktop/JsonProblem/JsonProblem.Web/
LOG: Initial PrivatePath = C:\Users\John\Desktop\JsonProblem\JsonProblem.Web\bin
LOG: Dynamic Base = C:\Users\John\AppData\Local\Temp\Temporary ASP.NET Files\vs\3661babd
LOG: Cache Base = C:\Users\John\AppData\Local\Temp\Temporary ASP.NET Files\vs\3661babd
LOG: AppName = 3b3fd45
Calling assembly : (Unknown).
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\Users\John\Desktop\JsonProblem\JsonProblem.Web\web.config
LOG: Using host configuration file: C:\Users\John\Documents\IISExpress\config\aspnet.config
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.config.
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).
LOG: Attempting download of new URL file:///C:/Users/John/AppData/Local/Temp/Temporary ASP.NET Files/vs/3661babd/3b3fd45/Newtonsoft.Json.DLL.
LOG: Attempting download of new URL file:///C:/Users/John/AppData/Local/Temp/Temporary ASP.NET Files/vs/3661babd/3b3fd45/Newtonsoft.Json/Newtonsoft.Json.DLL.
LOG: Attempting download of new URL file:///C:/Users/John/Desktop/JsonProblem/JsonProblem.Web/bin/Newtonsoft.Json.DLL.
LOG: Assembly download was successful. Attempting setup of file: C:\Users\John\Desktop\JsonProblem\JsonProblem.Web\bin\Newtonsoft.Json.dll
LOG: Entering download cache setup phase.
LOG: Assembly Name is: Newtonsoft.Json, Version=4.5.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed
LOG: A partially-specified assembly bind succeeded from the application directory. Need to re-apply policy.
LOG: Using application configuration file: C:\Users\John\Desktop\JsonProblem\JsonProblem.Web\web.config
LOG: Using host configuration file: C:\Users\John\Documents\IISExpress\config\aspnet.config
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.config.
LOG: Redirect found in application configuration file: 4.5.0.0 redirected to 6.0.0.0.
LOG: Post-policy reference: Newtonsoft.Json, Version=6.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed
LOG: GAC Lookup was unsuccessful.
LOG: The post-policy assembly reference requires probing again.
LOG: Attempting download of new URL file:///C:/Users/John/AppData/Local/Temp/Temporary ASP.NET Files/vs/3661babd/3b3fd45/Newtonsoft.Json.DLL.
LOG: Attempting download of new URL file:///C:/Users/John/AppData/Local/Temp/Temporary ASP.NET Files/vs/3661babd/3b3fd45/Newtonsoft.Json/Newtonsoft.Json.DLL.
LOG: Attempting download of new URL file:///C:/Users/John/Desktop/JsonProblem/JsonProblem.Web/bin/Newtonsoft.Json.DLL.
LOG: Assembly download was successful. Attempting setup of file: C:\Users\John\Desktop\JsonProblem\JsonProblem.Web\bin\Newtonsoft.Json.dll
LOG: Entering download cache setup phase.
LOG: Assembly Name is: Newtonsoft.Json, Version=4.5.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed
WRN: Comparing the assembly name resulted in the mismatch: Major Version
ERR: The assembly reference did not match the assembly definition found.
ERR: Setup failed with hr = 0x80131040.
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.

2 个答案:

答案 0 :(得分:1)

我有与上述问题描述完全相同的行为,除了当我重建我的类库(即JsonProblem.Core)时,它会引入Newtonsoft.dll 4.5.11,即使这个类库没有直接引用或Nuget包表示对NewtonSoft的引用。

在可能被视为Visual Studio 2015错误的情况下,类库重建将无形引用的DLL复制到引用项目bin文件夹(当前未构建),在引用项目中覆盖DLL,破坏它们。

IOW,例如,构建项目Y(引用JsonProblem.Core),显然是成功的。构建项目X(引用JsonProblem.Core),打破项目Y.构建项目Y,现在打破项目X.无限循环:while(sane){build(); }

就我而言,我在这个库中引用的唯一的第三方库是Gibraltar.Agent和Gibraltar.Agent.Web.Mvc(它报告没有依赖于NewtonSoft。在项目参考中右键单击这些并选择&# 34;找到依赖于这个模块的代码&#34;显示我不需要引用第二个。

我在Nuget中卸载了Gibraltar.Agent.Web.Mvc,所有问题都消失了。两天的DLL地狱心痛已经结束。

答案 1 :(得分:0)

您可能在这里处理了一些不同的场景。我给你的建议是使用fuslogvw工具向你展示它试图加载的dll,以及它在哪里寻找它。由于装配绑定重定向在表面上看起来正确,因此可能存在另一个在此处被屏蔽的依赖性问题。 fuslogvw工具只允许您查看程序集绑定行为以及发生了什么。拥有装配绑定问题真的很棒。

相关问题