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

时间：2013-01-07 15:46:17

标签： c# visual-studio visual-studio-2012 dependency-management projects-and-solutions

我们最近升级到VS2012和.NET 4.5。自切换到2012以来，我在调试时经常遇到这些错误：

  

编译器错误消息：BC32206：项目当前包含   引用NPGUtilities的多个版本，直接   参考版本2012.4.4751.24389和间接引用   （通过'AdminWeb.targetweights.sgModels'）到版本   2012.4.4751.24391。更改直接引用以使用NPGUtilities版本2012.4.4751.24391（或更高版本）。

     

BC32206：该项目目前包含对多个项目的引用   EnterpriseData的版本，直接引用版本   2012.4.4751.25227和间接引用（通过'SponsorWeb.selectplan.AdministratorXDataset1'）到版本   2012.4.4751.25243。更改直接引用以使用EnterpriseData版本2012.4.4751.25243（或更高版本）。

这两个都是项目参考。我试过删除并读取它们但仍然没有运气。任何人都可以就如何解决这个问题提出任何建议吗？

16 个答案:

答案 0 :(得分：12)

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

答案 1 :(得分：1)

首先解决方法：我禁用了程序集版本Autoincrement！

请注意，仅在Vs2013中出现此问题，且解决方案的副本与vs2010完美匹配。 Vs2013构建，重建，清洁解决方案，手动删除./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中有些东西是真实存在的。

所以最后一次机会：我禁用了Autoincrement，并将Assembly版本固定为XY0.0：这对我的目的来说已经足够了，因为'60 .dll'是综合版本的一部分，不应该单独部署（I仍然使用fileVersion浏览正确的文件）

答案 2 :(得分：0)

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

答案 3 :(得分：0)

我有同样的'明显'问题，这让我花了整整一天试图解决。我彻底检查了我的项目依赖项，并且都指向了相同版本的违规dll。我甚至修改了我的本地文件夹并将所有内容从Subversion中取出 - 仍然是相同的。我运行了Process Explorer并搜索了dll，却发现.NET Reflector正在引用旧的dll。在使用不同的Visual Studio解决方案调试旧版本之前几天我使用过.NET Reflector，.NET Relector在其中一个文件夹中引用了旧的dll。这可能会节省一些时间。

答案 4 :(得分：0)

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

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

更正启动文件夹为我更正了这一点。

答案 5 :(得分：0)

我们有类似的问题，干净无法解决。事实证明，bin文件夹偶然包含在项目中，因此引用的dll已签入版本控制。撤消包含并从repo中删除dll就可以了。

答案 6 :(得分：0)

我能够通过改变来清除报告的冲突 [assembly：AssemblyVersion（“1.0。*”）]到[assembly：AssemblyVersion（“1.0.5814.0”）]在'offending'项目的AssemblyInfo.cs文件中。

基于以下观察，这似乎是一个IDE问题：

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

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

此外，似乎只有C＃类库才会带来这种行为。

答案 7 :(得分：0)

远程调试时遇到此错误。正在调试的机器上引用的dll的版本在功能上是相同的，但与编译时引用的版本号不同。修复是替换正在调试的机器上的版本。

答案 8 :(得分：0)

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

我做了'替换'，然后在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>

答案 9 :(得分：0)

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

答案 10 :(得分：0)

我有一个使用JSON.net v10和现代版ASP身份的项目。 JSON.net使用的是旧版本的http.formatting dll - 通过Nuget升级到最新版本解决了它。

答案 11 :(得分：0)

正如其他人提到的，此错误可能是由于项目的AssemblyInfo.file中的自动增量功能引起的。

我们最初的AssemblyVersion就像

<Assembly: AssemblyVersion("4.6.1")>
我改为的

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

那是错误。我开始遇到这个问题。我以为我只需要删除。*，但仍然无法正常工作，因为没有。*的程序集的版本号比自动生成的版本号低。

为此，我在web.config文件的“名称空间”部分中引用了该程序集。我删除了它并运行了项目，出现了一些运行时错误。然后我重新添加了名称空间项，错误消失了。

如果您的程序集位于web / app.config的名称空间部分，请试一下。

编辑：执行此技巧后，我的一位同事仍然遇到了问题。 更好的解决方案是只清除临时ASP .NET文件夹。 （C：\ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ ASP.NET临时文件）

答案 12 :(得分：0)

我的问题是Microsoft.SqlServer.SMO组的dll。我的决心与其他所有人完全不同。请注意，这是Visual Studio 2017 v15.8.6中的问题。据我所知，这个问题有多种原因，我的解决方案不是清洗或装配自动编号。

在工作区1中，除了在工作区2中外，所有东西都已建立，这是由于以下原因：Microsoft.SqlServer.SMO命名空间中大约有10个dll都设置为特定版本。正确找到了8个dll，这些dll被直接引用并特定于版本。但是2有一个提示路径，但不是特定于版本的，也没有在提示路径中找到。因此，它默认使用最新版本的GAC中的这两个。一旦我将丢失的两个dll复制到提示路径中，并将它们设置为特定于版本，就一切正常了。

为了确保这一点，我确实手动编辑了项目文件，以将每个引用设置为所需的较早版本，并且还为了更好地将app.config中的Assembly Binding Redirect添加了到较旧的版本。

答案 13 :(得分：0)

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

我正在开发一个平台，该平台允许使用第三方花园提供的各种SDK开发第三方插件。

第三方插件被编译为DLL并上传到平台，并使用巫毒教和随机的家禽牺牲来加载（请阅读：不确定如何动态加载）。

简单地说，我的问题是主程序和我的第三方DLL都在引用“ fred.dll”。但是我引用的是“ fred.dll”的1.1版，而不是程序已加载的“ fred.dll”的1.0版。在我的第三方组件中引用1.0版的“ fred.dll”可以解决我的问题。

答案 14 :(得分：-1)

在我的情况下，清洁和构建工作正常

答案 15 :(得分：-2)

尝试删除所有bin / debug / * stuffs

相关问题
最新问题