該項目當前包含對多個版本的引用

Question

我們最近升級到 VS2012 和 .NET 4.5。 自從切換到 2012 年以來，我在調試時不斷收到這些錯誤：

編譯器錯誤消息：BC32206：該項目當前包含對多個 NPGUtilities 版本的引用、對版本 2012.4.4751.24389 的直接引用和對版本 2012.4.4751.24391 的間接引用（通過“AdminWeb.targetweights.sgModels”）。 更改直接引用以使用 NPGUtilities 的 2012.4.4751.24391（或更高版本）版本。

BC32206：該項目當前包含對多個 EnterpriseData 版本的引用、對版本 2012.4.4751.25227 的直接引用和對版本 2012.4.4751.25243 的間接引用（通過“SponsorWeb.selectplan.AdministratorXDataset1”）。 將直接引用更改為使用 EnterpriseData 的 2012.4.4751.25243（或更高版本）版本。

這兩個都是項目參考。 我試過刪除和閱讀它們，但仍然沒有運氣。 任何人都可以提供有關如何解決此問題的任何建議嗎？

Answer 1

我能夠通過刪除bin文件夾中的所有文件然后重建項目來解決這個問題。 對我來說，問題是清理項目只是刪除bin\\Debug文件夾中的 DLL，而舊的 DLL 保留在bin\\Release文件夾中。

Answer 2

首先解決方法：我禁用了程序集版本自動增量！

注意這個問題只在vs2013中出現過，有一份vs2010完美運行的解決方案。 vs2013 Build,rebuild,clean解決方案，手動刪除./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 中確實存在一些問題。

所以最后的機會：我禁用了自動增量並將程序集版本固定到 XY0.0：這對我的目的來說已經足夠了，因為“60.dll”是綜合版本的一部分，永遠不應該單獨部署（我仍然使用瀏覽正確文件的文件版本）

Answer 3

正如錯誤消息所示，您的庫存在版本沖突。 檢查引用的版本以確保它們匹配，或者更好的是，確保您在主項目和子項目中使用對同一文件的引用。

Answer 4

我有同樣的“明顯”問題，我花了一整天的時間試圖解決。 我已經徹底檢查了我的項目依賴項，並且都指向了相同版本的有問題的 dll。 我什至取消了我的本地文件夾並將所有內容從 Subversion 中取出 - 仍然相同。 我運行了 Process Explorer 並搜索了 dll，結果發現 .NET Reflector 引用了舊的 dll。 在調試不同 Visual Studio 解決方案中的舊版本之前幾天，我使用了 .NET Reflector，而 .NET Relector 正在引用其文件夾中的舊 dll。 這可能會為某人節省一些時間。

Answer 5

我發現問題是因為我無意中設置了錯誤的啟動文件夾。 例如，我的 PROJECT_A 依賴於 PROJECT_B，而 PROJECT_A 應該是啟動項目。 但是，我沒有意識到 PROJECT_B 現在是啟動文件夾。

PROJECT_A 使用對 PROJECT_B dll 的舊引用進行編譯，然后 PROJECT_B 隨后創建新版本並將該新版本復制到 bin 文件夾。

更正啟動文件夾為我糾正了這個問題。

Answer 6

我們有一個類似的問題，清理沒有解決。 結果是一個 bin 文件夾意外地包含在項目中，因此引用的 dll 被簽入到版本控制中。 撤消包含並從 repo 中刪除 dll 可以解決問題。

Answer 7

我能夠通過在“違規”項目的 AssemblyInfo.cs 文件中將 [assembly: AssemblyVersion("1.0.*")] 更改為 [assembly: AssemblyVersion("1.0.5814.0")] 來清除報告的沖突。

根據以下觀察，這似乎是 IDE 問題：

• 每次啟動 Visual Studio 都會報告不同的版本；
• 例如，在修訂版 1.0.5814.18599 和 1.0.5814.18600 之間。
• 而所有 bin 文件夾中的實際修訂版本為 ...17929。

顯然，VS 在啟動時會檢測並“緩存”沖突。 Clean 或 Rebuilt 沒有任何幫助。

此外，似乎只有 C# 類庫會帶來這種行為。

Answer 8

我在遠程調試時遇到了這個錯誤。 被調試機器上引用的 dll 版本在功能上相同，但版本號與編譯時引用的版本號不同。 修復是替換正在調試的機器上的版本。

Answer 9

我通過編輯 .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>

Answer 10

我只是進入“NuGet”並卸載了與沖突庫相關的所有包。 然后我再次小心地重新安裝，確保每個項目都具有相同（最新）的版本號。 我正在使用“cEfSharp”模塊，但錯誤地安裝了版本 57 和 51 的混合物。

Answer 11

我有一個使用 JSON.net v10 和現代版本的 ASP Identity 的項目。 JSON.net 使用的是舊版本的 http.formatting dll - 通過 Nuget 升級到最新版本為我解決了這個問題。

Answer 12

正如其他人所提到的，此錯誤可能是由於項目的 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\\Temporary ASP.NET Files)

Answer 13

我的問題是 Microsoft.SqlServer.SMO 的 dll 集。 我的決心再次與其他人完全不同。 請注意，它與 Visual Studio 2017 v15.8.6 一起使用。 據我所知，此問題有多種原因，我的解決方案與清潔或裝配自動編號無關。

在工作區 1 中，所有內容都已構建，但在工作區 2 中我遇到了上述問題，原因是：Microsoft.SqlServer.SMO 命名空間有大約 10 個左右的 dll 都設置為特定版本。 8 個 dll 被正確找到，直接引用和特定於版本。 然而 2 有一個提示路徑，但不是特定於版本的，也沒有在提示路徑中找到。 因此，它將這兩個默認為在更新版本的 GAC 中找到的那些。 只要我將丟失的兩個 dll 復制到提示路徑中，並將它們設置為特定於版本，就一切正常。

並且只是為了確保，我確實手動編輯了項目文件以設置對所需舊版本的每個引用，並且還在 app.config 中將程序集綁定重定向添加到舊版本以進行良好測量。

Answer 14

我的故事可能更像是一個邊緣案例，但值得注意的是。

我正在開發一個允許開發 3rd 方插件的平台，使用他們提供的各種 SDK。

第 3 方插件被編譯為 DLL 並上傳到平台，它們使用伏都教和隨機家禽犧牲加載（閱讀：不確定它們是如何動態加載的）。

簡單地說，我的問題是主程序和我的第 3 方 DLL 都引用了“fred.dll”。 但我引用的是“fred.dll”的 1.1 版，而不是程序加載的“fred.dll”的 1.0 版。 在我的 3rd 方組件中引用“fred.dll”的 1.0 版修復了我的問題。

Answer 15

就我而言，清理和構建工作正常

Answer 16

嘗試刪除所有 bin/debug/* 的東西