程序集引用不匹配問題探究

進行插件式編程的時候,常常性地彈出這麼個東西找到的程序集清單定義與程序集引用不匹配。 (異常來自 HRESULT:0x80131040),每每這種問題特別難以解決,搞定了一個還要出另一個。得研究一下怎麼處理。html

引用不匹配

這裏提示須要加載一個4.2.0.0版本的dll,我先看看文件夾下面有沒有對應的dll,查看文件dll的詳細信息。
git

這個版本號4.6.27818.1和4.2.0.0也差的有點太遠了吧,是這個問題?其實不是的,這個地方顯示的版本和程序集的版本不是一回事。github

程序集版本

.NET程序有不少版本的說法,官方對這個有解釋,經過文件管理器得到的版本是AssemblyFileVersion,而程序集加載器定位的版本使用的是AssemblyVersion,這兩個東西徹底不是一回事。經過右鍵,咱們看不到AssemblyVersion,比較簡單的方式,能夠經過Powershell腳原本查看程序集版本。shell

ls *.dll -r |
    ForEach-Object {
        try {
            $_ | Add-Member NoteProperty FileVersion ($_.VersionInfo.FileVersion)
            $_ | Add-Member NoteProperty AssemblyVersion (
                [Reflection.AssemblyName]::GetAssemblyName($_.FullName).Version
            )
        } catch {}
        $_
    } |
    Select-Object Name,FileVersion,AssemblyVersion

能夠看到,我這邊的程序集是4.2.0.1版本的,不是4.2.0.0版本的,所以,程序集不能正常加載。
編程

我本身的項目是使用nuget進行包管理的,引用的包的版本號是4.5.3(又多一個版本...),程序集版本是4.2.0.1。我找遍了整個項目,都沒有找到我dll項目中關於4.2.0.0版本的引用,苦思良久,打盹的時候突然想起來,是否是那個exe的問題?安全

綁定重定向

個人主exe程序是使用.NET Framework 4.6.1進行編譯,而後單獨編譯dll做爲插件放入一個文件夾,由exe程序進行加載。那有多是exe引用了4.2.0.0這個版本,或者是其餘dll插件引用了這個版本,形成版本不兼容。app

這種狀況能夠有不少種解決方案,這篇文章寫的很是詳細,推薦讀一讀。而我這裏使用了最簡單也是做者比較推薦的辦法,程序集引用的綁定重定向。工具

使用這個方法有一個前提,你須要徹底瞭解其餘程序引用這個程序版本的時候不會出問題,通常小版本號的變更,是相對比較安全的。性能

一直以來,我寫.NET Framework程序貌似就不多有這種問題,是由於微軟會自動給程序設置重定向,咱們能夠經過在項目上右鍵,點選自動生成綁定重定向。
ui

以後,會出現一個app.config文件,它會在生成程序的時候,變成程序名稱.dll.config的形式,裏面大概是這個樣子的:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Threading.Tasks.Extensions" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.2.0.1" newVersion="4.2.0.1" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

能夠發現,這個東西對咱們引用的版本內容進行了限制,強制某個範圍內的版本重定向爲一個固定的版本號。不過,雖然dll中已經有這個內容,可是exe不會理會它的,它只會看本身主程序的.exe.config文件。因此咱們須要作的,就是把這一個部份內容搬到主程序的.exe.config中。

修改後從新運行,而後有又提示找不到System.Buffers.dll了,如法炮製,問題解決。

Fusion Log

有時候,經過這個方法找下去,處理完了,也不必定可以解決,由於這個錯誤提示的是「未能加載文件或程序集或它的某一個依賴項。」,也多是某個引用的依賴項出了問題,這樣就不是很好找了。

好在.NET提供了一個程序集綁定日誌的工具,能夠幫助咱們查看綁定的問題。通常狀況下,這個東西是關閉的,系統會提示:

警告: 程序集綁定日誌記錄被關閉。
要啓用程序集綁定失敗日誌記錄,請將註冊表值 [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD)設置爲 1。
注意: 會有一些與程序集綁定失敗日誌記錄關聯的性能損失。
要關閉此功能,請移除註冊表值 [HKLM\Software\Microsoft\Fusion!EnableLog]。

調試的話,能夠打開這個註冊表鍵值。或者簡單點,直接使用Fuslogvw.exe(程序集綁定日誌查看器),用管理員帳號啓動,在設置中設置好記錄的日誌信息,而後就能夠記錄了,詳細的使用方法,見這裏。就能看到詳細的信息了,能夠幫助咱們深刻分析內部綁定的問題。(用完記得關,有性能損失。)

=== 預綁定狀態信息 ===
日誌: DisplayName = System.Threading.Tasks.Extensions, Version=4.2.0.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51
 (Fully-specified)
日誌: Appbase = file:///C:/Temp/360zip$Temp/360$0/
日誌: 初始 PrivatePath = NULL
調用程序集: DependencyWalker, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null。
===
日誌: 此綁定從 default 加載上下文開始。
日誌: 未找到應用程序配置文件。
日誌: 使用主機配置文件: 
日誌: 使用 C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config 的計算機配置文件。
日誌: 策略後引用: System.Threading.Tasks.Extensions, Version=4.2.0.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51
日誌: 相同的綁定已出現過,因 hr = 0x80070002 而失敗。

Dependency Walker

說到dll的引用,就有必要提一提很是有名的一個工具Dependency Walker,它能夠查看PE文件的引用狀況,可是這個程序好久沒有更新了,對.NET很不友好。我找了一下,發現幾個替代:

  1. Dependencies

這個工具能夠認爲是Dependency Walker的升級版,能夠查看PE文件的引用信息,對.NET也能夠支持,不過看的信息太少了,也沒法顯示缺失的狀況。

  1. DependencyWalker.Net

這個工具是專門爲.NET設計的,能夠查看程序集的引用狀況,我刪除了我插件的幾個dll,而後看就是這個樣子,一目瞭然,版本號也很是清楚。

經過這些工具,能夠幫咱們找一找究竟是dll的問題,也許會對「試圖加載格式不正確的程序。」、「引用不匹配。」等引用相關問題有所幫助。

這些工具處理的大可能是靜態引用,對於使用動態引用的,通常是不支持的。

總結

插件式編程極大加強了程序的拓展能力,不過,在處理程序集引用的時候,須要很是當心不一樣插件帶來的引用問題。程序設計的時候,可使用不一樣文件夾隔離不一樣的插件dll,並經過一些技巧來加載(能夠查看以前的文章)和隔離,這樣,就能夠避免出現不匹配的錯誤了。

參考資料

相關文章
相關標籤/搜索