為什么要保護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 防止破解的效果。
.NET產品源碼保護演示下載：www.dllprotect.com
作者QQ:6458450
注：由此帶來的問題
一、性能問題：每次調用都動態編譯肯定會影響性能，但是我們可以通過緩存來解決這個問題，第一次調用時就將編譯后的對象存於緩存中。
二、平台問題：非托管代碼不能生成ANYCPU類型的DLL，所以需要發布時指定兩個版本（X86/64）生成相應的版本的DLL，由安裝包判斷目標平台屬性，然后輸出對應的DLL。
三、發布問題：每次發布時需要先生成相應項目依賴者的HASH值再存於非托管代碼中再生成，放於安裝包中，步驟略顯復雜，但是為了安全，這個應該可以接受吧。
----------------------------------------------------------------------------
.net dll保護系列
--------------------------------------------------------------------------------------------
.NET DLL 保護措施詳解(一)（非混淆加密加殼）
.NET DLL 保護措施詳解(二)關於性能的測試
.NET DLL 保護措施詳解(三)最終效果
.NET DLL 保護措施詳解(四)各操作系統運行情況
.NET DLL 保護措施詳解(五)常規條件下的破解