错误 CS1705：“其版本高于引用的程序集”答案

【问题标题】：Error CS1705: "which has a higher version than referenced assembly"错误 CS1705：“其版本高于引用的程序集”
【发布时间】：2012-03-02 10:52:31
【问题描述】：

我已经对此进行了一段时间的调查，但尚未解决。我收到以下错误消息：

Compiler Error Message: CS1705: Assembly 'My.Model, Version=1.1.4422.23773, Culture=neutral, 
PublicKeyToken=bfde95ba233094b2' uses 
'Common, Version=3.3.4273.24368, Culture=neutral, PublicKeyToken=bfde95ba233094b2' 
which has a higher version than referenced assembly
'Common, Version=3.3.4269.17112, Culture=neutral, PublicKeyToken=bfde95ba233094b2'

c:\WINDOWS\assembly\GAC_MSIL\Common\3.3.4269.17112__bfde95ba233094b2\Common.dll: 
(Location of symbol related to previous error)

Web 服务器正在运行 Server 2003。我去了 c:\windows\assembly，实际上注意到列出了 3 个版本的 Common.dll。列出的最高版本是 3.3.4269.17112

我将版本为 3.3.4273.24368 的 dll 复制到程序集目录中。然后我重新编译并重新部署了我的代码（可能有点矫枉过正，但很好）。当我在新会话中打开浏览器并再次访问站点 URL 时，仍然收到相同的消息。

我可以使用 Windows 资源管理器并验证现在也列出了更高版本的 Common.dll。

我还可以研究什么来解决这个问题？我不想将程序集中的引用更改为指向旧版本。

【问题讨论】：

疯狂的*.* 版本号。重建一切，只有这样才能确定。

标签： .net web-deployment

【解决方案1】：

我有这个错误是因为“重建”并没有真正重建。

解决方法：关闭Visual Studio，真的去删除bin文件夹，然后重建，可能会更好。

此外，Visual Studio 有时会谎报引用，因此请检查 .csproj 文件中的 HintPath。

【讨论】：

这个救了我的培根。在本地运行很好，但我发布了一个更改，事情变得古怪。删除在线 bin 文件夹的内容会迫使事情恢复同步。谢谢！

【解决方案2】：

如果您使用的是 NuGet，则值得前往“管理 NuGet 包以获取解决方案”，找到导致问题的包并点击更新。然后它应该将所有软件包升级到最新版本并解决问题。

值得一试，因为它既快速又简单。

【讨论】：

这为我解决了，谢谢。不过我的情况略有不同：它没有在更新中列出，所以我必须去安装，并且有一个窗口显示每个项目的包版本。我正在将一些旧模块升级到新版本的 cms，所以我必须转到有问题的包，选择它们并单击安装。可能是因为 cms 刚刚改用 nuget，但您为我省去了很多乏味的 csproj 编辑！
确保在解决方案级别而不是项目级别更新 NuGet 包。
这当然应该是公认的答案，我没有读过这个但无意中尝试了我的解决方案，这就像一个魅力。
是的，如果您被允许更新的话。但这并不总是答案。我在一个更新会导致问题的项目中（不能使用最新的 .NET 的持久功能，因为 Microsoft 的配置抽象在那里中断） - 所以我有一种情况，我需要 downgrade 直到 Microsoft 获得配置抽象已修复！将 EF 核心从 5.x 降级到 3.x！然后它不仅仅是一键点击，因为 VS 项目“记住”你使用的是新版本并吐出错误！

【解决方案3】：

3 个想法供您尝试：

确保您的所有 dll 都是针对相同版本的 Common 编译的。
检查您的解决方案中是否有项目引用而不是文件引用。
在您的 web.config 中使用 binding redirections。 (Originally linked version at wayback machine)

【讨论】：

在wayback machine 和microsoft 仍然可用

【解决方案4】：

我的问题是我有 2 个项目引用了具有不同版本的同一个 dll 的 2 个不同副本。我通过删除它们并确保它们引用相同的 dll 文件来修复它。

【讨论】：

【解决方案5】：

一个可能的原因是第二个程序集安装在 GAC 中，而第一个程序集的版本号更高，被添加到项目的引用中。要验证这一点，请双击项目引用中的程序集，并检查对象浏览器中是否有另一个同名的程序集。

如果是这种情况，请使用 gacutil.exe 实用程序从 GAC 中卸载第二个程序集。例如，如果这些是 64 位程序集：

C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\x64\gacutil.exe -u <assembly_name>

【讨论】：

两年后，你的建议就像一个魅力。在对象浏览器中查看引用对其进行了排序。

【解决方案6】：

如果解决方案中的多个项目中的 nuget 包不同，则会出现此问题。

您可以通过将 nuget 包更新到通用版本来解决此问题，其中包含解决方案中的所有项目

【讨论】：

确保并查看错误消息中的项目文件，它会告诉您哪个不符合标准

【解决方案7】：

转到引用并添加导致问题的 dll 文件的新引用，并确保所有 dll 都针对相同的版本进行编译。它对我有用，我希望它也对你有用。

【讨论】：

【解决方案8】：

我的团队刚刚在我们的构建环境中遇到了这个问题。该问题是由于 .csproj 文件的元素存在差异。

我们的通用程序集具有指向包含我们的参考程序集的目录的正确相对路径。依赖程序集具有来自以前目录结构的路径。该解决方案在开发机器上成功编译，因为 GAC 解决了依赖项对安装在 C:\Program Files 中的正确版本的引用。构建环境有一个旧的程序集安装（即使它应该没有），它回落到这个错误。在文本编辑器中更新更正了问题。

【讨论】：

【解决方案9】：

我有同样的错误。我在将Microsoft.AspNetCore.ALL 安装到测试项目后修复了该错误。

【讨论】：

【解决方案10】：

在我的场景中，我为我的 dotnetCore 应用编辑了 .csproj 文件。我注意到 TargetFramework 标记的值为 netcoreapp2.1 而 RuntimeFrameworkVersion 标记的值为 2.0.0。所以我将RuntimeFrameworkVersion改为2.1.0，保存，重启VS并重建，然后它解决了错误。

希望对你有所帮助...

祝你好运，

苏格山

【讨论】：

【解决方案11】：

遇到了类似的问题。我的问题是我在同一个解决方案中有几个项目，每个项目都引用一个特定版本的 DLL，但版本不同。解决方案是在所有引用的所有属性中将“特定版本”设置为 false。

【讨论】：

【解决方案12】：

我知道这是很久以前在尝试了上述一些步骤之后提出的。对我有帮助的是以下步骤和this article。

我找到了引用并将 PublicKeyToken 从被引用的那个更改为旧的。

我希望这也有帮助。

【讨论】：

【解决方案13】：

我手动删除了 bin 和 obj 文件夹，重新构建，它工作了

【讨论】：

【解决方案14】：

在更新一些实体框架 NuGet 包后，我在 Visual Studio 2019 上发生了类似的事情。也许有人会偶然发现这个与实体框架或其他 NuGet 包相关的问题。

在我的例子中，项目依赖是指比依赖项目（包含引用）更高版本的 Nuget 包。

出于某种原因，在 .csproj 文件中，Microsoft.EntityFrameworkCore.Tools 的 PackageReference 条目包含标签 PrivateAssets。也就是说，looking at the documentation:

这些资产将被消耗，但不会流向父项目

在我的情况下，所需的行为是父项目包含依赖项目及其依赖项，因为这减少了相关项目之间 NuGet 包的重复。

因此，将子项目的.csproj文件从：

<PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="5.0.11">
  <PrivateAssets>all</PrivateAssets>
  <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
</PackageReference>

收件人：

<PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="5.0.11" />

然后重建，解决了这个问题。

【讨论】：

【解决方案15】：

手工制作的dll的收藏文件夹
如果您的解决方案有一个用于存放来自不同库的 dll 文件的垃圾文件夹
lib、source、libs 等
如果您在 Visual Studio 中打开解决方案（第一次），您可能会遇到此问题。并且您的 dll 的收集文件夹因某种原因丢失或丢失了具体的 dll 文件。

Visual Studio 将尝试以静默方式自行替换 dll 的引用。如果 VS 成功，那么您的本地解决方案将保持一个新的引用。不适用于其他克隆/结帐。

即您的 <HintPath> 将被忽略，您的项目文件 (.csproj) 不会更改。
以我为例

<Reference Include="DocumentFormat.OpenXml, Version=2.0.5022.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
  <SpecificVersion>False</SpecificVersion>
  <HintPath>..\..\..\lib\DocumentFormat.OpenXml.dll</HintPath>
</Reference>

DocumentFormat.OpenXml 将引用自 C:\Program Files (x86)\Open XML SDK\V2.5\lib 而不是 solution\..\lib 文件夹。

快速解决方法

检查并恢复您的 dll 的收集文件夹
从解决方案资源管理器执行卸载项目，然后重新加载项目。

正确的解决方法是迁移到 NuGet 包管理器。

【讨论】：

【解决方案16】：

对于 SharePoint，请确保在您的根文件夹下没有包含 DLL 的“bin”文件夹，如果有，只需将其删除。（并在VS中将“Copy Local”更改为false）。

【讨论】：

【解决方案17】：

网站项目中的引用存储在其 web.config 文件中。更新那里的引用以修复错误。

我花了一些时间查看解决方案中的所有引用，然后才意识到我忘记了 web.config 文件中的引用。

【讨论】：

【解决方案18】：

我在使用 UnitTestingProject 时遇到了同样的问题，在 MainProject 中我使用的是“System.Web.Mvc，Version=3.0.0.0”，而在 UnitTestingProject 中我使用的是“System.Web.Mvc，Version=3.0.0.1”

更改以下内容 <Reference Include="System.Web.Mvc, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL"> <HintPath>..\packages\Microsoft.AspNet.Mvc.3.0.50813.1\lib\net40\System.Web.Mvc.dll</HintPath> </Reference>

【讨论】：

【解决方案19】：

我在将 Episerver Find 添加到我们的站点并为 Episerver Find 安装相应的 NuGet 包后得到了这个。

修复很简单：同时更新所有与 Episerver 相关的插件（即使它们看起来不相关：CMS、CMS.TinyMCE、CMS.UI 等）

更新所有可能的 Episerver 插件并重新编译后，错误消失了。

【讨论】：

【解决方案20】：

在您的项目中找到参考System.Web.Mvc检查版本。

然后右键单击references -> assembly 并搜索system.web.mvc 并setup 它。

问题导致这些程序集的版本不同。

编辑：选择管理 NuGet 包并安装更新（如果您有多个项目也为它们安装更新。）

重要的更新是 Microsoft.AspNet.Mvc 和 Microsoft.Net.Compilers 别忘了！

【讨论】：

【解决方案21】：

在我们的团队中，我们使用 git 在不同的计算机上工作。有人更新了dll，但我没有。我刚刚更新了我的依赖项引用，问题就解决了。

【讨论】：

【解决方案22】：

我有一个类似的问题，我创建了一个DLL，即A.dll，它引用了其他DLL，即B.dll。

我创建了一个应用程序 C.exe 并引用了 DLL A.dll 和 B.dll。

解决方案 - 在从 c.exe 中删除 B.dll 的引用时，我能够解决问题。

希望这会有所帮助。

【讨论】：