問題的提出
晚上翻著群裡的聊天,發現一個有趣的問題:如何通過編碼方式來判斷一個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及其以上版本測試通過,如您有更多精力,可對其以下版本進行分析。
文章出處:http://anytao.net