项目当前包含对多个版本的引用

我能够通过删除我的bin文件夹中的所有文件，然后重建项目来解决这个问题。对我来说，问题是清理项目只是删除bin'Debug文件夹中的dll，而旧的dll则保留在bin'Release文件夹中。

首先解决方法:我禁用了程序集版本自动增量!

注意，这个问题只发生在Vs2013中，解决方案的副本在vs2010中完美运行。Vs2013 Build, rebuild, clean solution，手动删除。/bin或。/obj或%TEMP%都不能解决问题。我还在Vs2013中从头开始编写了一个新的解决方案，以避免vs2010中的尸体:这个新解决方案只编译了两次:第三次错误再次出现，没有任何方法…机器里有东西一直很脏。

现在解释一下…

我在86项目的解决方案上遇到了同样的问题，如下所述:'60.dll'是错误的dll:

- 99.exe 
-- 80.dll
---- 70.dll
------- 60.dll
-- 81.dll
-- 82.dll
---- 60.dll

所以BC32206错误发生的原因是:

The project '99.exe' currently contains references to more than one version of '60.dll, 
a direct reference to version 4.11.5618.23545 and an indirect reference (through '82.dll') to version 4.11.5618.23549. 
Change the direct reference to use version 4.11.5618.23549 (or higher) of '60.dll'

请注意，版本只有从23545到23549的修订不同(所以只有'4'单位):在一些重建中，这个差异是'1'单位;记住这个数字是(秒从午夜/2)，我意识到，由于某种原因，'60.dll'被编译了两次…无能为力:我没有找到任何不同的'60.dll'副本，其日期时间对应于更高值的请求'23549'。所以在Vs2013中确实存在bug。

所以最后的机会:我禁用了自动增量，并将汇编版本固定到X.Y.0.0:这对我的目的来说已经足够了，因为'60.dll'是一个全面发布的一部分，不应该单独部署(我仍然使用fileVersion来浏览正确的文件)

正如错误消息所示，您与库有版本冲突。检查引用的版本以确保它们匹配，或者更好的是，确保您在主项目和子项目中使用对相同文件的引用。

我有同样的"明显"问题，花了我一整天的时间试图解决。我已经彻底检查了我的项目依赖关系，所有这些都指向同一个版本的违规dll。我甚至关闭了我的本地文件夹，把所有东西从Subversion中取出来——还是一样的。我运行进程资源管理器并搜索dll，只发现旧的dll被。net反射器引用。几天前，我使用。net Reflector在不同的Visual Studio解决方案中调试旧版本，而。net Reflector引用了其中一个文件夹中的旧dll。这可能会节省一些时间。

我发现这个问题是因为我无意中设置了错误的启动文件夹。例如，我有一个依赖于PROJECT_B的PROJECT_A，并且PROJECT_A应该是启动项目。然而，我没有意识到PROJECT_B现在是启动文件夹。

PROJECT_A在编译时使用了对PROJECT_B dll的旧引用，然后PROJECT_B随后创建了一个新版本，并将该新版本复制到bin文件夹中。

纠正启动文件夹为我纠正了这个问题。

我们有一个类似的问题，一个清理没有解决。结果是，一个bin文件夹意外地包含在项目中，因此引用的dll被检入到版本控制中。撤销include并从repo中删除dll就成功了。

我可以通过更改来清除报告的冲突[assembly: AssemblyVersion("1.0.*")]到[assembly: AssemblyVersion("1.0.5814.0")]在'违规'项目的AssemblyInfo.cs文件中。

根据以下观察，这似乎是一个IDE问题:

• 每次启动Visual Studio都会报告不同的版本;
• 例如，在版本1.0.5814.18599和1.0.5814.18600之间
• 而所有bin文件夹中的实际版本是…17929.

显然，VS在启动时检测并"缓存"冲突。"清洁"或"重建"都没有帮助。

而且，似乎只有c#类库才能实现这种行为。

我在远程调试时遇到了这个错误。被调试的机器上引用的dll的版本在功能上是相同的，但与编译时引用的版本号不同。解决方法是替换正在调试的机器上的版本。

我通过编辑。dtsx文件并将所有实例的"Microsoft SQL Server'100'SDK'Assemblies"替换为"Microsoft SQL Server'120'SDK'Assemblies"，解决了SSIS包中所有脚本任务的问题。

我做了"替换"，然后在VS 2013中刷新，所有的错误都消失了。

注意，引用已经引用了版本12，但"HintPath"仍然引用了"'100'"路径。我想这就是问题的根源。

下面是.DTSX文件前后的XML片段:

:

<ItemGroup>
    <Reference Include="Microsoft.SqlServer.ManagedDTS, Version=12.0.0.0, Culture=Neutral, PublicKeyToken=89845dcd8080cc91">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>..'..'..'..'..'..'..'..'Program Files (x86)'Microsoft SQL Server'100'SDK'Assemblies'Microsoft.SQLServer.ManagedDTS.dll</HintPath>
    </Reference>
    <Reference Include="System" />
    <Reference Include="System.Data" />
    <Reference Include="System.Windows.Forms" />
    <Reference Include="System.Xml" />
    <Reference Include="Microsoft.SqlServer.ScriptTask, Version=12.0.0.0, Culture=Neutral, PublicKeyToken=89845dcd8080cc91" />
  </ItemGroup>

:后

 <ItemGroup>
    <Reference Include="Microsoft.SqlServer.ManagedDTS, Version=12.0.0.0, Culture=Neutral, PublicKeyToken=89845dcd8080cc91">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>..'..'..'..'..'..'..'..'Program Files (x86)'Microsoft SQL Server'120'SDK'Assemblies'Microsoft.SQLServer.ManagedDTS.dll</HintPath>
    </Reference>
    <Reference Include="System" />
    <Reference Include="System.Data" />
    <Reference Include="System.Windows.Forms" />
    <Reference Include="System.Xml" />
    <Reference Include="Microsoft.SqlServer.ScriptTask, Version=12.0.0.0, Culture=Neutral, PublicKeyToken=89845dcd8080cc91" />
  </ItemGroup>

我只是进入"NuGet"并卸载了与冲突库相关的所有软件包。然后我小心地重新安装了一次，确保每个项目都有相同的(最新的)版本号。我正在使用"cEfSharp"模块，但错误地安装了版本57和51的混合物。

我有一个使用JSON.net v10和现代版本ASP Identity的项目。JSON.net使用的是旧版本的http。格式化dll -通过Nuget升级到最新版本解决了我的问题。

正如其他人提到的，这个错误可能是由于AssemblyInfo中的自动增量特性引起的。项目文件。

我们最初有像

这样的AssemblyVersion

<Assembly: AssemblyVersion("4.6.1")>

我改成了

<Assembly: AssemblyVersion("4.6.1.*")>

这是错误的。我开始有这个问题。我以为我只需要删除。*，但它仍然不起作用，因为没有。*的程序集的版本号比自动生成的版本号低。

因此，为了修复，我在web的命名空间部分引用了该程序集。配置文件。我删除了它并运行了项目，得到了一些运行时错误。然后我添加了名称空间项，错误就消失了。

如果你的程序集在web/app.config的命名空间部分，请尝试一下。

编辑:我的一个同事在做了这个技巧之后仍然有这个问题。一个更好的解决方案是简单地清除临时asp.net文件夹。(C: ' Windows ' Microsoft.NET ' Framework64 ' v4.0.30319 '临时ASP。. NET Files)

我的问题是与Microsoft.SqlServer.SMO一组dll有关。我的决心又和其他人完全不同了。请注意，它是在Visual Studio 2017 v15.8.6中使用的。从我收集到的信息来看，这个问题有多种原因，我的解决方案不是清洁，也不是组装自动编号。

在工作空间1的一切，但在工作空间2我有上述问题，由于这个:Microsoft.SqlServer.SMO命名空间有大约10个左右的dll全部设置为特定版本。正确找到了8个dll，直接引用和特定于版本。然而，2有一个提示路径，但不是特定于版本的，也没有在提示路径中找到。因此，它将这两个默认为在最新版本的GAC中找到的。只要我将缺少的两个dll复制到提示路径中，并将它们设置为特定于版本的，就可以工作了。

为了确保，我手动编辑了项目文件，将每个引用设置为所需的旧版本，并且还在app.config中添加了Assembly Binding Redirect到旧版本。

我的故事可能更像是一个边缘案例，但值得注意。

我正在开发一个允许第三方插件开发的平台，使用他们提供的普通SDK。

第三方插件被编译为dll并上传到平台，并且它们使用巫毒和随机家禽献祭来加载(阅读:不确定它们是如何动态加载的)。

简单地说，我的问题是主程序和我的第三方DLL都引用了"fred.dll"。但是我引用的是"fred.dll"的1.1版本，而不是"fred.dll"的1.0版本。程序已经加载。引用"fred.dll"在我的第三方组件修复了我的问题。

在我的情况下，清理和构建工作良好

尝试删除所有bin/debug/*的东西