無法加載文件或程序集或其依賴項之一

Question

我遇到了另一個“無法加載文件或程序集或其依賴項之一”的問題。

附加信息：無法加載文件或程序集“Microsoft.Practices.Unity，Version=1.2.0.0，Culture=neutral，PublicKeyToken=31bf3856ad364e35”或其依賴項之一。 找到的程序集的清單定義與程序集引用不匹配。 （HRESULT 異常：0x80131040）

我不知道是什么原因造成的，也不知道如何調試它來找到原因。

我在我的解決方案 catalogs.csproj 文件中進行了搜索，在我擁有 Unity 的每個地方我都有：

Reference Include="Microsoft.Practices.Unity, Version=2.0.414.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL"

在我的任何項目中都找不到任何違反 1.2.0.0 的參考。

我應該如何解決此問題的任何想法 go？

Answer 1

1. 檢查您是否正在引用一個程序集，而該程序集又引用了舊版本的統一。 例如，假設您有一個名為ServiceLocator.dll的程序集，它需要舊版本的 Unity 程序集，現在當您引用ServiceLocator您應該為它提供舊版本的 Unity，這就產生了問題。

2. 可能是所有項目構建其程序集的輸出文件夾，具有舊版本的統一。

您可以使用FusLogVw找出誰正在加載舊程序集，只需為日志定義一個路徑，然后運行您的解決方案，然后檢查（在 FusLogvw 中）加載 Unity 程序集的第一行，雙擊它並查看調用組裝，然后開始。

Answer 2

打開 IIS 管理器

選擇應用程序池

然后選擇您正在使用的池

進入高級設置（在右側）

將啟用 32 位應用程序 false 的標志更改為 true。

Answer 3

對我來說，其他解決方案都不起作用（包括清理/重建策略）。 我找到了另一種解決方法，即關閉並重新打開 Visual Studio 。

我想這會迫使 Visual Studio 重新加載解決方案和所有項目，重新檢查流程中的依賴項。

Answer 4

嘗試清理解決方案中的 Debug 和 Release 文件夾。 然后刪除並再次添加統一。

Answer 5

99% 的無法加載文件或程序集或其依賴項問題之一是由依賴項引起的！ 我建議您按照以下步驟操作：

1. 從http://www.dependencywalker.com/下載Dependency Walker

2. 啟動Dependency Walker並打開 dll（在我的情況下NativeInterfaces.dll ）

3. 您可以看到一個或多個帶有紅色錯誤的dll錯誤打開文件...

4. 這意味着您的系統中缺少此 dll； 在我的情況下，dll 名稱是MSVCR71.DLL

5. 您可以從 google 下載缺少的 dll 並復制到正確的路徑中（在我的情況下是c:\\windows\\system32 ）

6. 此時必須在GAC（Global Assembly Cache）中注冊新的dll：打開DOS終端，寫入：

    cd \\Windows\\System32 regsvr32 /i msvcr71.dll

7. 重新啟動您的應用程序

Answer 6

盡管最初的問題是五年前發布的，但問題仍然存在並且相當煩人。

一般的解決方案是對所有引用的程序集進行徹底分析，以了解出了什么問題。 為了使這個任務更容易，我制作了一個工具（一個 Visual Studio 擴展），它允許選擇一個 .NET 程序集（一個.dll或.exe文件）來獲取所有引用程序集的圖形，同時突出顯示沖突或丟失的引用。

該工具在 Visual Studio Gallery 中可用： https : //marketplace.visualstudio.com/vsgallery/051172f3-4b30-4bbc-8da6-d55f70402734

輸出示例：

Answer 7

Microsoft Enterprise Library（由 .NetTiers 引用）是我們的問題，它又引用了舊版本的 Unity。 為了解決這個問題，我們在 web.config 中使用了以下綁定重定向：

<configuration>
    <runtime>
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
            <dependentAssembly>
                <assemblyIdentity name="Microsoft.Practices.Unity" publicKeyToken="31bf3856ad364e35" culture="neutral" />
                <bindingRedirect oldVersion="1.0.0.0-2.0.414.0" newVersion="2.1.505.0" />
            </dependentAssembly>
            <dependentAssembly>
                <assemblyIdentity name="Microsoft.Practices.Unity.Configuration" publicKeyToken="31bf3856ad364e35" culture="neutral" />
                <bindingRedirect oldVersion="1.0.0.0-2.0.414.0" newVersion="2.1.505.0" />
            </dependentAssembly>
        </assemblyBinding>
    </runtime>
</configuration>

或者，您可能只想將企業庫更新到最新版本。

Answer 8

以下為我工作。

• 刪除臨時文件 C:\\Windows\\Microsoft.NET\\Framework\\v4.0.30319\\Temporary ASP.NET Files
• 關閉 VSTS 並再次打開
• 刪除和添加相同的 DLL（注意：您添加相同的匹配版本）

Answer 9

檢查項目中的 Web.config/App.config 文件。 查看版本號是否正確。

<bindingRedirect oldVersion="X.X.X.X-X.X.X.X" newVersion="X.X.X.X" />

這對我有用。

Answer 10

在解決方案資源管理器中右鍵單擊項目（不是解決方案），在構建選項卡中選擇平台目標：“任何 CPU”。

Answer 11

Juntos 的回答是正確的，但您還應該考慮：

對於 unity v2.1.505.2 ，指定了不同的AssemblyVersion和AssemblyFileVersion屬性：

NuGet 使用了AssemblyFileVersion ，但 CLR 並不關心它！ CLR 將只使用AssemblyVersion ！

因此，您的重定向應應用於在AssemblyVersion屬性中指定的版本。 所以應該使用2.1.505.0

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
 <assemblyIdentity name="Microsoft.Practices.Unity" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-2.1.505.0" newVersion="2.1.505.0" />
</dependentAssembly>
</assemblyBinding>

另請參閱： AssemblyVersion、AssemblyFileVersion 和 AssemblyInformationalVersion 之間有什么區別？

Answer 12

我也遇到了這個可怕的錯誤，並為此找到了解決方案......

1. 右鍵單擊解決方案名稱
2. 單擊清潔解決方案
3. 重新啟動 Visual Studio
4. 轉到項目屬性>>構建
5. 更改配置以發布
6. 開始調試 (F5)

1) , 2)

4) , 5)

希望這也能幫助你。

Answer 13

不確定這是否有幫助。

檢查程序集中的屬性中的程序集名稱和默認命名空間是否匹配。 這解決了我的問題，產生了同樣的錯誤。

Answer 14

• 轉到：解決方案->包
• 單擊高級選項卡（在頁面下方查找）
• 將您的dll添加到其他程序集（這樣我們可以在 sharepoint 中添加外部 dll）。

Answer 15

就我而言，bin 文件夾中是一個名為 Unity.MVC3 的非引用 dll，我嘗試在 Visual Studio 中搜索對此的任何引用，但沒有成功，因此我的解決方案非常簡單，只需從 bin 文件夾中刪除該 dll。

Answer 16

我遇到了同樣的問題，我通過以下說明解決了它：

1. 打開工具菜單並選擇選項
2. 在選項中，窗口轉到項目和解決方案/Web 項目
3. 檢查use the 64bit version of IIS ...

Answer 17

謝謝 Riddhi M. 以下為我工作。

刪除臨時文件 C:\\Windows\\Microsoft.NET\\Framework\\v4.0.30319\\Temporary ASP.NET Files Close VSTS and Open Again Remove and Add the same DLLs (注意：你添加了相同的匹配版本)

Answer 18

以下為我工作。

• 刪除臨時文件 C:\\Windows\\Microsoft.NET\\Framework\\v4.0.30319\\Temporary ASP.NET Files
  • 然后右鍵單擊 Temporary Asp.net Files>properties>security 並授予對 IIS 和所有運行我的項目的用戶的完全控制訪問權限

Answer 19

這個問題發生在我身上，當父庫期望編譯“x64”時，我的一個依賴庫正在編譯帶有“任何 CPU”的 DLL。

Answer 20

你說你的解決方案中有很多項目......好吧，從一個靠近構建順序頂部的項目開始。 建立一個，一旦你弄清楚了，你就可以對其余的應用相同的修復程序。

老實說，您可能只需要刷新您的參考。 聽起來您要么更新了版本但沒有更新引用，要么如果您將解決方案保留在源代碼管理中，則這是一個相對路徑問題。 只需驗證您的假設，然后重新添加引用即可。

Answer 21

您必須從輸出文件夾中刪除您的 appname.dll 文件。 清理調試和發布文件夾。 重建並復制到輸出文件夾重新生成的 dll 文件。

Answer 22

我“設置為啟動項目”卸載/未找到的庫/項目。

然后部署了它。

它奏效了！

我認為它無法找到 .dll，因為它最初不在程序集中。

Answer 23

如果您通過在 Windows xp 上打開應用程序收到此錯誤消息，則意味着您首先安裝了該應用程序，因為它在沒有 net framework 4 和 service pack 3 的情況下無法運行。 您一次又一次地安裝了此錯誤，因此您應該再次重新安裝該應用程序，但首先從添加和刪除中卸載

如果這不起作用，請不要虐待我。 我也是小學生

Answer 24

另一個可能的原因：確保您沒有意外地在項目屬性中為這兩個項目指定了相同的程序集名稱。

Answer 25

我使用企業庫 5 的 .NET 4.0 解決方案是添加對以下內容的引用：

Microsoft.Practices.Unity.Interception.dll

Answer 26

留意相互沖突的引用。 即使在清理和重建之后，沖突的引用仍然會導致問題。 我的問題是在 AForge 和 Accord 之間。 我刪除了兩個引用，並重新添加了引用，重新選擇了特定的引用（特別是我的情況，只是 Accord）。

Answer 27

對我來說，在沒有 Unity C# Projects Checkmark 的情況下重建 Unity 游戲有效。

Answer 28

就我而言，建議的答案都沒有奏效。

這是對我有用的：

1. 刪除引用
2. 重命名 DLL
3. 再次導入引用

第二步顯然很重要，因為沒有它它就無法工作。

Answer 29

嘗試檢查引用的“復制到本地”屬性是否設置為 true 並且特定版本是否設置為 true。 這與 Visual Studio 中的應用程序相關。

Answer 30

我今天遇到了這個問題，就我而言，問題很奇怪：

  <dependentAssembly>
    <assemblyIdentity name="Microsoft.Owin.Host.SystemWeb" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-3.1.0" newVersion="3.1.0.0" />
  </dependentAssembly>0.

請注意 XML 末尾的雜散字符 - 不知何故，這些字符已從版本號移動到此 XML 塊的末尾！

  <dependentAssembly>
    <assemblyIdentity name="Microsoft.Owin.Host.SystemWeb" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-3.1.0.0" newVersion="3.1.0.0" />
  </dependentAssembly>

更改為以上，瞧！ 一切都恢復了。

Answer 31

清理解決方案，然后右鍵單擊項目和 select Package

這里增加Assembly和Assembly file版本並重建。

如果這不起作用，

1 - 在文件資源管理器中打開解決方案。

2 - 關閉 Visual Studio。

3 - 刪除所有bin和obj文件夾。

4 - 重新打開項目並構建它。

Answer 32

好吧，這聽起來可能非常愚蠢，但繼續嘗試其他所有解決方案並在這個愚蠢的事情上過夜后，我是如何解決這個問題的。

我從Bin文件夾中丟失了一些DLL時遇到了同樣的錯誤。 我試圖刪除，從Team Foundation Server備份所有內容但沒有工作。 從我的office-matelocal機器獲得了Bin文件夾的副本，並將其替換。 它也沒用。 最后，我手動FTP服務器，獲得了顯示為丟失的DLL副本，然后它開始顯示文件列表序列中的下一個文件丟失。

所以我ftped服務器得到了所有Bin文件夾，手動逐個替換每個文件。 （不是Ctrl + All並替換..我試過：它不起作用。）不知何故它起作用了......

Answer 33

我的解決方案是：

我有一個三層應用程序，我忘記將 DLL 也復制到 IIS 的正確路徑。 將它復制到正確的位置后，它對我有用。

Answer 34

我在 Visual Studio 2015 中的 web forms 項目中不斷收到此錯誤。我關閉了 Visual Studio 並殺死了 ScriptedSandbox64.exe、Microsoft.VsHub.Server.HttpHostx64.exe、Microsoft.VsHub.Server.HttpHostx.exe .VisualStudio.Web.Host.exe *32 個進程，它似乎有助於解決問題。

Answer 35

我執行以下操作來確定找不到哪個依賴項。

運行 regedit.exe 並導航到：

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion

創建以下內容：

LogFailures set value to 1 (DWORD)
LogResourceBinds set value to 1 (DWORD)
LogPath (String) set value to C:\FusionLog\

現在運行您的程序並等待它引發Could not load file or assembly or one of its dependencies 。

使用資源管理器，導航到C:\FusionLog並且應該有一個包含程序日志的文件夾，顯示缺少哪個依賴項。

注意：有些人使用 FUSLOGVW.exe，它是這些 Fusion Logs 的查看器。 在我的機器上可以在多個地方找到它，包括：

C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.7.2 Tools\x64\FUSLOGVW.exe

Answer 36

我有這個問題，這個錯誤實際上很愚蠢。 我為 .dll 文件指定了錯誤的位置，在將位置更改為正確的位置后，加載正確發生（回答所以其他人不要犯這個錯誤）。

Answer 37

對我來說，Nuget 似乎對我的項目/解決方案不太好。 I used Nuget to install NewtonSoft.Json The project file seemed to reference it correctly, and when I R-clicked the dll name in Solution Explorer/Dependencies/Nuget, then clicked Properties, I found that the dll existed where properties said it should be .

I deleted the Nuget package and did R-click Project > Add > Reference and browsed to the dll in a packages directory when a former Nuget process had installed it, and then the Solution ran fine.

注意：這個解決方案是一個大雜燴，從 Xamarin.iOS 解決方案開始，並添加一個 .netstandard 項目（這是我在使用 Nuget 時遇到困難的地方）。 解決方案中還有一個“便攜式”項目。 我從一個已經離開 3 年的開發人員那里繼承了這一切。 哈哈。

Answer 38

我有一個名為 SetTags 的 C# Winforms 項目，其中包含大量 forms，我使用 Visual Studio 2013 進行處理。 在編輯其中一個並嘗試構建后，我得到了錯誤：

Could not load file or assembly 'SetTags Version = 2.1.85.0, Culture=neutral,PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.

當我嘗試保存項目或關閉我一直在處理的表單時，也會出現該錯誤。

我通過刪除最近添加的單選按鈕控件並注釋掉對其的所有引用來解決問題，然后再次添加控件並取消注釋代碼。 這使我可以保存表單，並在關閉重新啟動 VS 時問題消失了。

我的 Visual Studio 環境偶爾會出現許多問題 - 工具箱不顯示或僅在 VS 啟動時出現，嘗試在設計模式下查看表單時無法識別的自定義控件 - 可能是我需要轉到更高的 VS 版本。

Answer 39

對我來說是一個奇怪的修復，但我剛剛從源代碼管理中提取了這個解決方案。

收到此錯誤，查看了上面的大部分答案，然后刪除了解決方案並從源代碼管理中重新提取了解決方案。

工作。

只適用於少數人，但我想我是少數人之一，所以會有更多。 不知道第一次發生了什么，但不知何故，當我把它們拉過來時，某些組件一定有一些問題。

基本上將其關閉並再次打開。

Answer 40

我也在這個問題上浪費了幾個令人沮喪的時間。 我們不得不更新我們的 .NET 框架版本，並開始為幾個多年未更改的 DLL 獲取多個“無法加載文件或程序集或其依賴項之一”。 奇怪的是，在錯誤消息中搜索的版本都非常舊。 例如，它正在搜索 Newtonsoft.Json 版本 6.0.0，而我們多年來一直使用 8.0.1。

恢復到這些舊版本不是一種選擇，無論如何，我們的 web.config 文件中有一堆bindingRedirect元素，它們應該將對舊 DLL 的調用重定向到新的 DLL。 回滾 .NET 版本使錯誤 go 消失，但我們需要新版本。 到底是怎么回事？

我們的 web.config 文件中的<runtime>元素包含以下元素：

<assemblyBinding appliesTo="v2.0.50727"
    xmlns="urn:schemas-microsoft-com:asm.v1">

似乎被忽略的dependentAssembly元素包含在其中。

罪魁禍首是appliesTo屬性。 這意味着bindingRedirect僅適用於 .NET 版本 2.0.50727。 當我們更新 .NET 框架版本時，我們所有的 bindingRedirect 元素都被忽略了。

在我們的案例中，解決方案是完全刪除appliesTo屬性。

Answer 41

您的項目的 csproj 文件必須包含 Microsoft.Practices.Unity 的 package 引用，並且在 global-packages 文件夾 (%userprofile%.nuget\packages) 中找不到此文件，運行dotnet restore可解決此問題

Answer 42

第 1 步：刪除現有參考 第 2 步：清理解決方案 第 3 步：再次添加項目參考。

並完成。 :)

Answer 43

TLDR； 我的解決方案是在 Visual Studio 中恢復默認設置。

---

我在 Visual Studio 2019 社區版上，我在我沒有接觸的不同項目中遇到了相同的 dll 文件的問題。

在嘗試了這個問題的所有答案后（截至 2020-07-22 7:13UTC），我決定修復 Visual Studio 安裝（事先備份了我的設置）。 安裝后打開有問題的解決方案，問題就消失了。 之后導入我的設置，問題又回來了。因此，無需再次修復 Visual Studio 安裝（這需要幾分鍾 + 一次重啟），我只是恢復了 VS 默認設置，然后它就可以工作了。 如果我最終有時間進行調查，我將編輯答案並查明潛在問題

Answer 44

嘗試按照建議關閉並重新打開 VS，但沒有成功。

我不得不從 MIXED PLATFORMS更改為 ANY CPU 。

Answer 45

我使用了神奇的工具“Fusion++” https://github.com/awaescher/Fusion