.NET选择了错误的引用程序集版本。

Question

我刚把一个现有的项目复制到一台全新的机器上开始开发，并遇到了一个关于我引用的程序集版本的问题（正好是 Telerik 的 DLL）。

项目最初引用了旧版本的程序集（我们称其为 v1.0.0.0）。我的新机器安装了程序集的最新版本，因此我认为我已经更新了它（我们称新版本为v2.0.0.0）。

现在的问题是：如果我将旧的 v1.0.0.0 dll 复制到项目文件夹并将其作为参考添加，那么网站就可以正常启动。但是，如果我删除该引用（并从系统中删除旧的 DLL），并添加新版本（v2.0.0.0），则页面会显示以下异常：

“无法加载文件或程序集“XXXXXX, Version=1.0.0.0, Culture=neutral, PublicKeyToken=121fae78165ba3d4”或它的某个依赖项。找到的程序集清单定义与程序集引用不匹配。(HRESULT 异常: 0x80131040)”

显然，代码正在寻找过时的版本并找不到它。但是为什么呢？

我在解决方案文件夹中搜索了该版本号，但没有找到任何引用。我仔细检查了 .csproj 文件的文本，发现版本正确显示为最新版本，而 HintPath 正确显示了新 DLL 的路径。此外，由于我没有在系统上安装旧 DLL，因此它不会出现在我的 GAC 中（尽管 v2.0.0.0 会出现，正如预期的那样）。

然后，我启用了 FUSLOGVW.exe 尝试弄清楚为什么它正在寻找该旧版本，但没有成功：

Assembly Load Trace: The following information can be helpful to determine why the assembly 'XXXXXX, Version=1.0.0.0, Culture=neutral, PublicKeyToken=121fae78165ba3d4' could not be loaded.


=== Pre-bind state information ===
LOG: User = MyComp\me
LOG: DisplayName = XXXXXX, Version=1.0.0.0, Culture=neutral, PublicKeyToken=121fae78165ba3d4
 (Fully-specified)
LOG: Appbase = file:///d:/My Documents/Visual Studio 2010/Projects/CoolProj/WebApp/
LOG: Initial PrivatePath = d:\My Documents\Visual Studio 2010\Projects\CoolProj\WebApp\bin
Calling assembly : WebApp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: d:\My Documents\Visual Studio 2010\Projects\CoolProj\WebApp\web.config
LOG: Using host configuration file: 
LOG: Using machine configuration file from C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Post-policy reference: XXXXXX, Version=1.0.0.0, Culture=neutral, PublicKeyToken=121fae78165ba3d4
LOG: Attempting download of new URL file:///C:/WINDOWS/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files/root/90233b18/10d54998/XXXXXX.DLL.
LOG: Attempting download of new URL file:///C:/WINDOWS/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files/root/90233b18/10d54998/XXXXXX/XXXXXX.DLL.
LOG: Attempting download of new URL file:///d:/My Documents/Visual Studio 2010/Projects/CoolProj/WebApp/bin/XXXXXX.DLL.
WRN: Comparing the assembly name resulted in the mismatch: Major Version
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.

它只是说它开始寻找旧的程序集。我已经尝试在网上寻找解决方案，看到了类似于这个SO问题，但它似乎与我的问题完全相反。那个提问者的程序找到了错误的DLL而不是被引用的DLL。而我的问题是，程序神秘地寻找错误的DLL，并且无法找到正确的DLL，尽管正确的DLL可以在bin文件夹和GAC中找到。

为什么我的程序会寻找旧版本？我在哪里可以搜索以找到这个错误的引用？

- Michael La Voie

Answer 1

我猜测你使用的另一个程序集正在引用旧的dll。 你是否熟悉所有其他正在使用的项目引用，并且它们中有任何一个引用了Telerik dlls？

你能否在web.config文件中加入类似于以下的绑定重定向？

<dependentAssembly>
 <assemblyIdentity name="Telerik" publicKeyToken="121fae78165ba3d4"/>
 <bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.0.0"/>
</dependentAssembly>

- Chris Conway

---

我曾经遇到过各种不同版本的加载/未加载类似的问题。你可以尝试另一个诀窍，就是手动删除C:/WINDOWS/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files/root/90233b18/10d54998文件夹中的所有文件。有时在重新编译网站时，ASP.Net无法清理该文件夹，因为某些文件锁定，这些dll可能会保留旧引用。值得一试，我知道在过去这个方法对我有效。 - Chris Conway

你曾经帮我解决过一个相关的问题，谢谢！我的 C# 应用程序中的一种继承形式在设计器中无法打开，因为它正在寻找旧版本的某个引用。结果发现，另一个引用最初是在引用该问题引用的旧版本时构建的。 - Sam Skuce

如果您对语法感到困惑：http://msdn.microsoft.com/en-us/library/0ash1ksb.aspx - Junior Mayhé

谢谢Chris！你在这里解决了我的问题：https://dev59.com/aWgu5IYBdhLWcg3wOUgk - Shaul Behr

您还可以查看您的 App.config 或 web.config 文件，看看是否存在 <dependentAssembly> 条目导致了问题。 - Roy Tinker

Answer 2

我尝试了大部分的答案，但仍然无法使其工作。对我而言，以下方法有效：

右键单击参考 -> 属性 -> 更改“特定版本”为false。

希望这能有所帮助。

- RayLoveless

---

投票+1的意思就是赞同。 - xr280xr

有时候，简单的点赞并不能充分概括回答让你有多开心和宽慰——在花费了数小时试图解决一个本不应该成为问题的愚蠢问题后，你尝试以不同的方式搜索并找到一种之前没有尝试过的解决方法，然后嘿！现在它终于奏效了！经历了这一切，有时仅仅按下点赞按钮并不能完全表达出那种压倒性的感觉：哥们，你真的救了我一命。 - Michael Plautz

Answer 3

我赞同Chris Conway的看法（投了他的赞）。问题在于，您在项目中引用了一个telerik程序集，而该程序集引用了另一个不存在的程序集。

首先，我不会将任何供应商（即：telerik）程序集安装到GAC中。Telerik的东西只编译为两个程序集（telerik.web.design和telerik.web.ui）。只需将它们与应用程序一起部署即可。

其次，在每个.proj文件（如.csproj）中，都会有一个指向Telerik.Web.UI文件。这通常包含版本号。确保放置在bin文件夹中的程序集与该版本匹配。

第三，确保所有项目都使用最新的程序集。还要确保它们从本地路径获取程序集，而不是从GAC获取。（我真的真的不喜欢GAC。它已经在我参与的某些项目中引发了无数问题）。我们通常有一个“Assemblies”文件夹，所有项目都用它来进行外部程序集引用。

第四，Visual Studio每次加载Web站点项目时会自动搜索您的gac，并重新定位程序集位置，如果它发现gac中存在某些内容。我不记得它是否对Web应用程序项目执行此操作，但我很久以前就没有遇到过这个问题。这可能会导致部署期间出现类似的问题。

第五，您可以在web.config中重新绑定程序集的版本号。在部分中，您可以使用类似以下内容的内容将2008年以来部署的每个telerik程序集指向一个非常特定的版本：

  <dependentAssembly>
    <assemblyIdentity name="Telerik.Web.UI" publicKeyToken="121fae78165ba3d4" />
    <bindingRedirect oldVersion="2008.0.0.0-2020.0.0.0" newVersion="2010.02.0713.35" />
  </dependentAssembly>

- NotMe

---

我的意思是“感觉”，这个问题困扰了我好几个月了 :) - Michael La Voie

Answer 4

尝试：

• 清理临时项目文件
• 清理构建和obj文件
• 清理安装在C:\Users\USERNAME\.nuget\packages\下的旧版本

这对我有用。

- delira

---

清理 C:\Users\USERNAME.nuget\packages\ 目录是我所缺少的。非常感谢！ - Herdo

为了清理旧的NuGet版本，在基于Windows的计算机上，点击“开始”并搜索“运行”>复制并粘贴“%userprofile%.nuget\packages”，即可打开NuGet版本文件夹。 - E.Meir

Answer 5

虽然这并不是一个明确的答案，但我们也遇到了这个问题，以下是我们的情况和解决方法:

开发人员1:

解决方案包含引用NuGet包的项目A和引用项目A的MVC项目。启用NuGet包还原，然后更新NuGet包。运行时出现错误，报告找不到NuGet库 - 但错误是它正在寻找旧的、未更新的版本。解决方案（这很荒谬）：在调用项目A的MVC项目中的第一行代码上设置断点。使用F11步进。解决了 - 再也没有问题。

开发人员2:

相同的解决方案和项目，但神奇的设置断点和步进解决方案不起作用。到处寻找版本重定向或其他对此Nuget包的坏引用，删除包并重新安装它，清除bin、obj、Asp.Net Temp，什么都没有解决。最终，将项目A重命名，运行MVC项目 - 解决了。将其重新命名为原始名称，问题得到了解决。

我没有任何解释为什么会起作用，但它确实使我们摆脱了严重的困境。

- Chris Moschini

Answer 6

1. 进入C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG
2. 找到machine.config文件
3. 用记事本打开
4. 查找冲突的dll
5. 移除该dll并保存。

编译程序集

addassembly=dllName,Version=1.0.0000.0000 Culture=neutral,PublicKeyToken="QWEWQERWETERY"

程序集编译

对我有效。

- Reynan de la Cruz

---

我也发现了这个噩梦 - 即使你从GAC中删除程序集，它仍然会在“C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\machine.config”中留下错误的版本引用。 - Evalds Urtans

Answer 7

您在该解决方案中还有其他项目吗？（可能是另一个项目引用了旧版本）通常在VS中，dll依赖跨越解决方案中的所有项目。

- AspNetDev

---

解决方案中没有其他项目，也没有其他引用telerik的DLL。我只引用Microsoft DLL，如System.*。 - Michael La Voie

Answer 8

我曾经遇到类似的问题，我不得不删除bin和obj文件夹中的所有内容并重新构建项目，才能解决我的问题。希望这可以帮到你。

- Edd

Answer 9

我得到的是：

无法加载文件或程序集“XXX-new-3.3.0.0”或其某个依赖项。所定位的程序集清单定义与程序集引用不匹配。(HRESULT 异常: 0x80131040)

这是因为我将程序集的名称从XXX.dll更改为XXX-new-3.3.0.0.dll。 将名称恢复为原始名称即可解决错误。最初的回答。

- mimo

---

是的 - 我们在我们的公共程序集库中的名称中包含了一个版本，以避免源代码控制中的命名问题。将名称更改回来并手动更新引用/提示路径，一切都正常工作。 - Mathew Paxinos

Answer 10

如果有人能够从我的经验中节省3小时的时间......我的情况略有不同。我的代码使用了DevExpress v11.1 v11.1.4.0，我在代码中正确地引用了它们。但是.net内存分析工具却在GAC中安装了DevExpress v11.1 v11.1.12.0。事实上，失败的并不是我引用的组件，而是它们内部引用的组件。无论我怎么尝试，GAC总是首先被检查。它编译和运行得很好，但我无法查看窗体设计器，堆栈跟踪也没有帮助。最终，我卸载了.net内存分析工具，一切恢复正常。

- RichieRich