有的時候，你在雙擊一個託管程序，或者使用Assembly.Load方法加載一些Assembly的時候，CLR會拋出System.FileNotFoundException，這種異常經常讓人誤解。例如有一個託管程序A，引用了dll B，雖然A和B都在同一個文件夾裏面，但是當你試圖運行A的時候，還是會有類似下面的異常拋出來：
|
Unhandled Exception: System.IO.FileLoadException: Could not load file or assembly 'TestLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=eb9fb5aa4f452bda' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
File name: 'TestLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=eb9fb5aa4f452bda' at App.Main() |
在工作當中，我發現很多程序員在資源管理器裏面雙擊程序以後，看到程序在啓動階段拋出異常就束手無措了，因爲這種異常不像程序在執行過程中發生的異常 — 還有機會調試，這種異常不能通過單步跟蹤的方式來發現問題所在。
像這種託管程序在資源管理器通過雙擊啓動時就拋出異常的情況，我建議大家在排錯的時候，首先在命令行程序裏面重新執行一下出錯的程序，當然啦，結果是一樣的 — 還是啓動不起來，但是在命令行裏面執行有一個好處，CLR會將完整的異常信息打印在命令行裏面，很多異常信息實際上都提供了豐富的錯誤原因描述，有的時候還提供了排錯需要使用的方法，例如下圖：
按照上面紅線高亮顯示的部分設置好註冊表對應的鍵值，並且重新執行一遍程序你就可以找出錯誤原因了。
除了上面說到的方法，CLR實際上還提供了一個叫做FUSLOGVW.exe的工具，也是可以用來檢查FileNotFoundException的原因的，用法如下：
1. 打開FUSLOGVW.exe，點擊“Settings…”按鈕。
2. 在彈出的對話框裏面選中“Log bind failures to disk”（告訴CLR將加載Assembly失敗的一些錯誤信息保存在磁盤裏）。
3. 爲了能夠看到錯誤信息，勾上“Enable custom log path”複選框，並且在“Custom log path”文本框裏面設置好保存的路徑（注意，只能填寫文件夾的完整路徑）
4. 重新執行發生錯誤的程序，發生FileNotFoundException異常以後，切換回FUSLOGVW.exe並點擊“Refresh”按鈕。
5. 這時候你應該可以在旁邊的列表框裏面看到有一些新列表項（都是加載失敗的Assembly的具體錯誤信息），雙擊其中一項就可以看到加載失敗的具體原因了。
