問題的提出
晚上翻着羣裏的聊天，發現一個有趣的問題：如何通過編碼方式來判斷一個dll或者exe爲debug build還是release build？由於沒有太多的討論，所以我只好自己找點兒辦法，試圖解決這個問題，爲夜生活帶點刺激。於是，便有了本文的探索和分析。
當然，爲了充分的調動起大家的主意，省去不必要的google操作，我覺得有必要對Debug和Release兩種模式的異同進行一點提綱挈領式的分析，從而爲接下來的解決方案打好基礎。
Debug & Release
我們應用Visual Studio對代碼文件進行F5操作（Build）時，實際是發生了一系列語法檢查、詞法檢查和編譯過程，通常情況下我們有兩種Build模式，這就是常說的Debug Build和Release Build。望文知意，Debug Build模式通常應用於開發時，便於調試反饋；而Release Build則應用於部署時，這是因爲Release模式下，編譯器做了很多的優化操作（代碼冗餘、循環優化等），省去了對調試信息的記錄。因此，兩種Build模式是各不相同的，我們對其二者進行一點總結如下：
- Debug用於開發時，Release用於部署時。
- Debug模式下，將產生pdb文件，用於保存狀態信息和調試信息；Release模式下，不產生調試信息，也沒有pdb文件。
- Debug模式下，System.Diagnostics.Debug.Write（或WriteLine）可以向跟蹤窗口（Output）輸出跟蹤信息；而Release模式下，System.Diagnostics.Debug.WriteLine將被忽略。不過，可以考慮System.Diagnostics.Trace.Write，其人緣較好，對Debug和Release左右通吃，都可輸出調試信息。
- Debug模式下，#define DEBUG將作爲默認預定義常量，參與編譯過程；而在Release模式下，該預編譯將被省略。例如如果執行：
#if DEBUG Console.WriteLine("Hi"); #endif
在Debug模式下，Console.WriteLine(“Hi”)將參與編譯，而Release模式下，會忽略該語句的執行。不過，如果你手動添加
#define DEBUG
在兩種模式下，都會執行Console.WriteLine(“Hi”)的編譯。究其原因，是Visual Studio在默認情況下預定義了#define DEBUG，我們可以通過開關來設置：
關於預編譯指令可詳查《你必須知道的.NET》的相關章節。
解決方案
既然對Debug Build和Release Build有個基本的瞭解，那麼也由此可以推斷我們解決開篇問題的依據。在.NET中以DebuggableAttribute來控制CLR如何處理模塊代碼規則，而屬性IsJITTrackingEnabled屬性來標識運行庫在代碼生成過程中是否跟蹤調試信息的標識，如果IsJITTrackingEnabled爲true，表示運行庫跟蹤調試信息，可推斷爲Debug Build模式；如果IsJITTrackingEnabled爲false，表示運行庫沒有跟蹤調試信息，可推爲Release Build模式。所以，解決的方案，最終着眼於對IsJITTrackingEnabled信息的獲取上，可想而知，最簡單的辦法莫過於神兵利器——反射。
那麼，我們開始吧。
構建
首先我們創建一個AnyContext來承載通用的上下文服務，在這裏主要包含的就是：
/// <summary> /// A common context /// </summary> /// <remarks> /// Anytao, http://www.anytao.com /// </remarks> public class AnyContext : IAnyObject { public static DebugMode GetDebugMode(string assemblyName) { } } 其中，DebugMode是一個簡單的枚舉：
/// <summary> /// Debug mode type /// </summary> /// <remarks> /// Anytao, http://www.anytao.com /// </remarks> public enum DebugMode { Debug, Release }
可向而知，我們需要實現一個根據Assembly信息獲取DebuggrableAttribute的Helper類，既然是Helper類我們希望能夠兼顧各種情況，因此通過泛型方法是做好的選擇，具體實現如下：
/// <summary> /// Common helper /// </summary> /// <remarks> /// Anytao, http://www.anytao.com /// </remarks> public static class Utils { /// <summary> /// Get GetCustomAttribute /// </summary> /// <typeparam name="T">CustomAttribute Type</typeparam> /// <param name="provider"></param> /// <returns></returns> public static T GetCustomAttribute<T>(this ICustomAttributeProvider provider) where T : Attribute { var attributes = provider.GetCustomAttributes(typeof(T), false); return attributes.Length > 0 ? attributes[0] as T : default(T); } }
此處的GetCustomAttribute被實現爲擴展方法，那麼任何實現了ICustomAttributeProvider接口的類型，都可以通過其獲取CustomAttribute了，例如：Type、Assembly、Module、MethodInfo，都可以實現對GetCustomAttribute的調用。
接下來，GetDebugMode的邏輯就變得很簡單，我們傳入assembly路徑即可獲取DebuggrableAttribute，並由此推導IsJITTrackingEnabled的情況：
public static DebugMode GetDebugMode(string assemblyName) { if (string.IsNullOrEmpty(assemblyName)) { throw new ArgumentNullException("assemblyName"); } DebugMode ret = DebugMode.Debug; try { // Get assebly by name Assembly ass = Assembly.LoadFile(assemblyName); // Get DebuggableAttribute info DebuggableAttribute att = ass.GetCustomAttribute<DebuggableAttribute>(); ret = att.IsJITTrackingEnabled ? DebugMode.Debug : DebugMode.Release; } catch (Exception) { throw; } return ret; } 好了，這就是一個簡單的判斷邏輯，在AnyContext中包含了很多諸如此類的上下文定義，而GetDebugMode提供了本文開頭的解決方案。
測試
- 新建兩個project，並分別以Debug模式和Release模式編譯，生成對應的exe（或dll）：
- debugass.exe
- releaseass.exe
- 新建TestProject，並對GetDebugMode進行測試如下：
[TestClass] public class AnyContextTest { [TestMethod] public void TestIsDebugOrRelease() { // Arrange string ass1 = @"D:\debugass.exe"; string ass2 = @"D:\releaseass.exe"; // Act string mode1 = AnyContext.GetDebugMode(ass1).ToString(); string mode2 = AnyContext.GetDebugMode(ass2).ToString(); // Asset Assert.AreEqual(mode1, "Debug"); Assert.AreEqual(mode2, "Release"); } }
一切OK，你不妨試試。
注：本測試在.NET 2.0及其以上版本測試通過，如您有更多精力，可對其以下版本進行分析。
參考文獻：
