為什麼要保護DLL，我就不多說了，各人有各人的理由。總的來說，就是不想核心邏輯洩露及授權驗證被破解兩大方面的因素。市面上的混淆加密工具對.NET原始碼保護的效果天差地別，很多網上下到的混淆工具破解版對.NET原始碼混淆保護的效果通常都不行（能找到對應的反混淆工具進行脫殼），而保護效果較好的混淆工具，收費比較高昂且也沒有破解版，導致很多小企業或個人開發者為.NET的原始碼的智慧財產權保護絞盡腦汁。

首先，我來介紹一下發布出去的DLL所面臨的風險：

一、直接引用

二、反編譯

三、反射

如果DLL一點措施都不做的話，上面任意一種都可以達到破解目的的。

然後，通常網上能搜到如下的保護方式，但真心的來說，用處不大，當然對小白破解者增加了難度。

一、混淆類的工具（如Dotfuscator，但是可以通過ILSpy、Reflector等反編譯哦，直接COPY程式碼也能執行）

二、加密類的工具（如MaxToCode，網上有相應的破解教程）

三、加殼類的工具（如Sixxpack，網上有相應的破解教程）

四、強簽名（簽名只是防止專案中的某一個DLL被篡改了，不能防止反編譯或反射的哦）

說了那麼多，難道沒有相對靠譜的方式了嗎？

最後，我們進入正題

上面那些工具的目的歸結出來大約完成兩個目的，一是不能看，二是不能調，當然，我們也是實現這兩個目的，只是手段不同。

一、不能看：.NET DLL可以包含託管堆程式碼（可以被反編譯的）與非託管堆程式碼（不能被反編譯，要反編譯也是更高層次的了，不在討範圍內），我們將核心邏輯程式碼置於非託堆程式碼中，由託管堆程式碼提供介面供外部呼叫，呼叫時將非託管程式碼通過.NET動態編譯特性編譯後返回執行結果。這樣就保證了不能看。

二、不能調：我們在非託管程式碼中加入驗證呼叫者來源功能，判斷呼叫者的HASH值是不是與在非託管程式碼中約定的HASH值(釋出時需要提前生成相關引用者的HASH值存於非託管程式碼，最後生成非託管程式碼的DLL放於安裝包中)一致，如一致則通過執行返回結果，不一致則返回空。這樣就解決了非合法來源不能調的問題。

此保護思路適用於有.net 原始碼加密、.net 原始碼加密、.net 程式碼保護、.net dll加密、.net dll保護、.NET 產品保護、asp.net原始碼加密、asp.net 程式碼保護、asp.net dll保護、C# 程式碼保護、C# dll保護、VB.net 程式碼保護、VB.net dll保護需求的使用者，能有效的保護.net原始碼及dll，達到.net 防止反編譯、.net程式碼防止反編譯、.net 防止破解、asp.net 防止反編譯、asp.net 防止破解、C# 防止反編譯、C# 防止破解、dll加密防止反編譯、dll防止反編譯、dll防止被呼叫、dll 防止別人呼叫、vb.net 防止反編譯、vb.net 防止破解的效果。

作者QQ:6458450

注：由此帶來的問題

一、效能問題：每次呼叫都動態編譯肯定會影響效能，但是我們可以通過快取來解決這個問題，第一次呼叫時就將編譯後的物件存於快取中。

二、平臺問題：非託管程式碼不能生成ANYCPU型別的DLL，所以需要釋出時指定兩個版本（X86/64）生成相應的版本的DLL，由安裝包判斷目標平臺屬性，然後輸出對應的DLL。

三、釋出問題：每次釋出時需要先生成相應專案依賴者的HASH值再存於非託管程式碼中再生成，放於安裝包中，步驟略顯複雜，但是為了安全，這個應該可以接受吧。

更多參考：