首页 文章

无法在MVC4 Web API中加载文件或程序集'System.Net.Http，Version = 2.0.0.0

提问于
浏览 次
91

我有点奇怪的问题 .
我使用MVC 4和新的Web API开发了一个应用程序，它在本地工作正常 . 我在服务器上安装了MVC4并部署了应用程序 . 现在我收到以下错误：

无法加载文件或程序集'System.Net.Http，Version = 2.0.0.0，Culture = neutral，PublicKeyToken = 31bf3856ad364e35'或其依赖项之一 . 定位的程序集的清单定义与程序集引用不匹配 . （来自HRESULT的异常：0x80131040）描述：在执行当前Web请求期间发生了未处理的异常 . 请查看堆栈跟踪以获取有关错误及其来源的更多信息

有趣的是，我在本地包含在我的包文件夹或ASP.NET MVC 4 \ Assemblies文件夹中的System.Net.Http版本是1.0.0.0 . 我实际上从我的项目中删除了对System.Net.Http的引用，但我仍然得到相同的消息 . 我有点困惑的是它从哪里获得2.0.0.0参考以及为什么它可以在本地工作但不在服务器上 .

查看nuget依赖项：

ASP.NET WEb API核心库（Beta）依赖于System.Net.Http.Formatting .
System.Net.Http.Formatting依赖于System.Net.Http .
我猜这就是它的来源 . 但我确实安装了这个软件包的2.0.20126.16343版本，它只是内部的dll版本为1.0.0.0

我错过了什么吗？

UPDATE:

这是另一个ASP.NET应用程序的子应用程序，但另一个仍然基于WebForms . 所以，有些东西搞砸了 . 但是，如果我在web.config中的汇编部分下执行清理，如果甚至不再找到应用程序本身 .

asp.net asp.net-mvc-4 asp.net-web-api

17 回答

  • 0

    将app应用到appharbor我遇到了同样的问题 . 问题是它还不支持.NET 4.5 . 我做了什么 .

    • 将我的项目切换到.NET 4.0配置文件 .

    • 卸载了Web API NuGet包 .

    • 再次安装Web API（Beta）NuGet包 .

    • 已验证.csproj文件包含所有引用的程序集，因此它始终从Bin文件夹而不是GAC中获取 .

    回复于
  • 0

    在IIS 6.0上部署先前转换的（从.NET 4.5到4.0）Web应用程序时，我遇到了同样的错误 .

    在我发现的web.config runtime 部分中

    <dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
    <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="4.0.0.0"/>
</dependentAssembly>

    我改成了

    <dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
    <bindingRedirect oldVersion="0.0.0.0-1.0.0.0" newVersion="2.0.0.0"/>
</dependentAssembly>

    现在就像魅力一样 .

    回复于
  • 1

    我的工作：

    Note the redirect of 1-4 to 2.0

    <dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a"   culture="neutral"/>
    <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="2.0.0.0"/>
</dependentAssembly>
    回复于
  • 0

    在项目的References文件夹中，应该有对此dll的引用，版本应为2.0.0.0 . 确保将其设置为Copy Local = true . 然后确保它找到了通往服务器应用程序bin文件夹的路径 .

    这是现在由nuget管理的库之一 . 所以打开Nuget并确保一切都是最新的 . 在您的项目包目录中，该文件应该在这里： \packages\System.Net.Http.2.0.20126.16343\lib\net40

    您还可以尝试创建一个新的MVC4应用程序，看看该文件是否显示该文件 .

    回复于
  • 0

    在我的情况下，我以一种更简单的方式修复它，只需给出一个HintPath来引用nuget包：

    <Reference Include="System.Data.Entity" />
     <Reference Include="System.Net.Http, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
       <Private>True</Private>
+      <HintPath>..\..\packages\Microsoft.Net.Http.2.0.20710.0\lib\net40\System.Net.Http.dll</HintPath>
     </Reference>
     <Reference Include="System.Net.Http.WebRequest, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
       <Private>True</Private>
+      <HintPath>..\..\packages\Microsoft.Net.Http.2.0.20710.0\lib\net40\System.Net.Http.WebRequest.dll</HintPath>
     </Reference>
     <Reference Include="System.Numerics" />
     <Reference Include="System.Security" />
    回复于
  • 2

    在我的情况下，我无意中通过NuGet向System.Net.Http版本2.1.10.0添加了依赖项 . 我无法在NuGet包管理器中摆脱它（因为其他包似乎依赖于它） . 但是，这些包不依赖于此特定版本 . 这是我为了摆脱它而做的（您也可以使用NuGet控制台（使用-force参数）：

    • 将packages.config中的Microsoft.Net.Http版本从2.1.10.0更改为2.0.0.0

    • 在NuGet软件包管理器中卸载BCL可移植包

    • 手动删除依赖库（System.Net.Http . *，其版本为2.1.10.0）

    • 添加对System.Net.Http 2.0.0.0的引用

    回复于
  • 1

    在文件配置中我删除了依赖汇编：

    <dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
    <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="2.0.0.0"/>
<dependentAssembly>

    现在它工作正常 .

    回复于
  • 1

    我在测试服务器（Windows 2008 R2）上遇到了这个问题，该服务器应该已经“准备好”进行部署;）

    提示是当我检查我的DEV机器和部署服务器之间的System.net版本时，它们不匹配 .

    使用以下步骤修复：

    • 从HERE下载的.NET Framework 4.5独立安装程序

    • 在部署计算机上运行安装程序

    在安装框架后，服务器需要重新启动，所以就这样做了volla！我们很高兴去！

    回复于
  • 30

    我们正在使用VS 2013，创建了一个新的MVC 4 Web API，并且在我们的TeamCity服务器上构建时遇到了system.net.http.dll不正确版本的问题，但它在我们使用VS 2013的本地开发人员计算机上构建得很好安装 .

    我们终于确定了问题 .

    在创建新的MVC 4 Web API并在项目创建时选择框架4.0时，我们发现DLL的正确NuGet包版本被放入：.. \ packages \ Microsoft.Net.Http.2.0.20710.0 \ lib \ net40 \ System.Net.Http.dll

    但是这个项目的.csproj文件说这个system.net.http.dll文件的路径是：.. \包\ Microsoft.Net.Http.2.0.30506.0 \ LIB \ net40 \ System.Net.Http.dll

    因此，当尝试构建时，此路径差异失败，但是在开发人员计算机上的其他位置找到了正确的文件框架版本，但在TeamCity构建服务器上却找不到 .

    到目前为止，这是我们发现的唯一区别 . 更改.csproj文件中的路径并使用VS2013在本地Dev机器上构建仍然可以找到 .

    检查到版本控制并拥有我们的TeamCity构建服务器（没有在本地安装VS 2013）现在在其NuGet包文件夹中找到该解决方案的正确版本.dll并成功构建而不是搜索另一个版本的system.net.http .dll并找到一个与框架不匹配的新版本，从而导致构建失败 .

    不确定这是否有帮助 .

    检查DLL的项目文件路径，并确保它与DLL的包文件夹路径匹配 .

    回复于
  • 10

    只是简化了对我有用的其他答案 .

    我去了NuGet管理器，卸载了相关的软件包（在我的例子中，“Microsoft ASP.NET Web API 2.1客户端库”和“Json.NET”）并重新安装它们 . 只需点击几下 .

    回复于
  • 1

    关闭项目，再次打开它 . 然后，清洁解决方案构建 . 适合我

    回复于
  • 2

    对于2.2.15.0版，我这样做了：

    <dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
    <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="2.2.15.0"/>
</dependentAssembly>
    回复于
  • 0

    我有同样的问题！我看了一下VS中的Warnings选项卡，发现我的一个nuget包是间接引用.NETFramework Version 4.5.0.0 . 我不得不卸载这个软件包，然后重新安装4.0版本，但一定要指定支持4.0的软件包版本（它默认回到4.5我相信如果你没有指定何时安装软件包） . 希望这可以帮助！

    回复于
  • 1

    我们在部署后在服务器上发生了这种情况 . 它是由以下原因引起的：

    A）bin文件夹中仍然存在的旧文件应该被删除

    要么

    B）没有对Application Pool Identity用户的文件夹的读访问权限 .

    换句话说，对于我们来说，这是通过修复站点文件夹的权限并擦除bin文件夹并重新部署来解决的 .

    回复于
  • 110

    我和Gembox.spreadsheet.dll版本31有同样的问题 .

    “无法加载文件或程序集'GemBox.Spreadsheet，Version = 39.3.30.1095，Culture = neutral，PublicKeyToken = b1b72c69714d4847'或其依赖项之一 . 找到的程序集的清单定义与程序集引用不匹配 . （HRESULT的例外情况： 0x80131040）“

    我从这些文章中尝试了几乎所有内容，但没有一个能够奏效它只是简单的步骤修复 .

    我尝试构建单独的项目，基本上设置了dll的正确版本引用，错误完全从解决方案中消失 .

    回复于
  • 0

    去一个类似的问题，许多评论中提到的指令运行正常

    <dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
    <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="2.0.0.0"/>
<dependentAssembly>

    虽然，您必须确保旧版本的覆盖率足够高，否则新版本可能无法重定向到您需要的特定版本，并且使用较新的引用的位置将无法正常工作，因为较旧的引用已经在bin目录中 .

    回复于
  • 0

    对于这个错误（和类似的），值得通过NuGet Consolidate（解决方案>管理NuGet包...）来确保在解决方案中引用的每个类库中相同的引用组件版本是一致的，因为即使稍微较旧的版本也可能具有依赖性在其他旧组件上 . 它与Updates一起使用非常简单，可以节省很多痛苦 .

    这为我解决了这个问题，我想说如果你正在创建也引用MVC或其他基于Web的NuGet组件的辅助库，那么必须熟悉它 .

    回复于

相关问题