一、C#預處理器指示符(詳細點擊連接到MSDN查看）
#if
#else
#elif
#endif
# define
#undef
#warning
#error
#line
#region
#endregion
#pragma
#pragma warning
#pragma checksum
二、詳細介紹
下面將對這些指令逐一介紹（轉錄自http://www.cnblogs.com/aivdesign/articles/1241775.html）
1. #define和#undef
#define可以定義符號。當將符號用作傳遞給#if指令的表達式時，此表達式的計算結果true。如
#define DEBUG
它告訴編譯器存在給定名稱的符號，在本例中是DEBUG。這個符號不是實際代碼的一部分，只在編譯代碼時存在。
#undef正好相反，它刪除一個符號。
必須把#define和#undef命令放在C#源碼的開頭，即在要編譯的任何代碼之前。它不像C++中那樣可以定義常數值。
#define本身并無大用，它需要配合#if指令使用。
如
#define DEBUG
int DoSw(double x)
{
#if DEBUG
COnsole.WriteLine("x is"+X);
#edif
}
2. #if, #elif, #else和#endif
這些指令告訴編譯器是否要編譯某個代碼塊。看下面的方法：
static void PrintVersion()
{ #if V3
Console.WriteLine("Version 3.0"); #elif V2
Console.WriteLine("Version 2.0"); #else
Console.WriteLine("Version 1.0"); #endif
}
上面的代碼會根據定義的符號來打印不同的版本信息。 這種方式成為條件編譯。
注意：
使用#if不是條件編譯代碼的唯一方式，C#還提供了通過Conditional屬性的機制。
#if和#elif還支持一組邏輯運算符!=，==，!=和|| 。如果符號存在，符號的值被認為是true，否則為false，如：
#if V3 || (V2 == true) // if 定義了V3或V2符號...
3. #warning和#error
這也是兩個很有用的預處理器指令，編譯器遇到它們時，會分別產生警告或錯誤信息。如果遇到#warning指令，會向用戶顯示#warning指令后面的文本。實際上，在VS2005中，IDE會直接將信息標識出來：
而如果編譯器遇到#error，就會立即退出編譯，不會產生IL代碼。
使用這兩個指令可以檢查#define是不示做錯了什么事，使用#warning可以讓自己想起做什么事。
#if DEBUG && RELEASE
#error "You 've define xxxx!"
#ednif
#warning "Don't forgot to removexxxxxx!"
Console.WriteLine("I have this job");
4. #region和#endregion
#region和#endregion指令用于把一段代碼標記為有指定名稱的一個塊，如下所示：
#region private methods
private int x;
private int y;
#endregion
這兩個指令不會影響編譯過程。但可以為VS編輯器所識別，從而使得代碼顯示布局更為清晰。
5. #line
可以用于改變編譯器在警告和錯誤信息中顯示的文件的名字和行號信息。如果編寫代碼時，在把代碼發給比編譯器前，要使用某些軟件包改變鍵入的代碼，可以使用這個指令，因為這意味著比編譯器的報告的行號或文件名與文件中的行號或編譯的文件名不匹配。#line指令可以用于恢復這種匹配也可以使用語法#line default 把行號恢復默認。
#line 164 "cORE.CS"
#LINE default
6. #pragma，#pragma warning，#pragma checksum
#pragma：為編譯器提供特殊的指令，說明如何編譯包含雜注的文件。
#pragma warning：可啟用或禁用某些警告。
#pragma checksum：生成源文件的校驗和，以幫助調試ASP.NET頁。
可以抑制或恢復指定的編譯警告。與命令行選項不同，#pragma指令可以在類和方法上執行，對抑制什么警告和抑制的時間進行更精細的控制。
#pragma warning disable 169
public class Aclass
{
int nFiled;
}
#pragma warning restore 169
三、更好的替代方案
利用條件屬性代替(轉錄自http://www.cnblogs.com/wucountry/archive/2007/02/13/649549.html)
使用#if/#endif 塊可以在同樣源碼上生成不同的編譯(結果)，大多數debug和release兩個版本。但它們決不是我們喜歡用的工具。由于#if/#endif很容易被濫用，使得編寫的代碼難于理解且更難于調試。程序語言設計者有責任提供更好的工具，用于生成在不同運行環境下的機器代碼。C#就提供了條件屬性(Conditional attribute)來識別哪些方法可以根據環境設置來判斷是否應該被調用。
這個方法比條件編譯#if/#endif更加清晰明白。編譯器可以識別Conditional屬性，所以當條件屬性被應用時，編譯器可以很出色的完成工作。條件屬性是在方法上使用的，所以這就使用你必須把不同條件下使用的代碼要寫到不同的方法里去。當你要為不同的條件生成不同的代碼時，請使用條件屬性而不是#if/#endif塊。
很多編程老手都在他們的項目里用條件編譯來檢測先決條件(per-conditions)和后續條件(post-conditions)。
(注：per-conditions，先決條件，是指必須滿足的條件，才能完成某項工作，而post-conditions，后續條件，是指完成某項工作后一定會達到的條件。例如某個函數，把某個對象進行轉化，它要求該對象不能為空，轉化后，該對象一定為整形，那么：per-conditions就是該對象不能為空，而post-conditions就是該對象為整形。例子不好，但可以理解這兩個概念。)
你可能會寫一個私有方法來檢測所有的類及持久對象。這個方法可能會是一個條件編譯塊，這樣可以使它只在debug時有效。
private void CheckState( )
{
// The Old way:
#if DEBUG
Trace.WriteLine( "Entering CheckState for Person" );
// Grab the name of the calling routine:
string methodName =
new StackTrace( ).GetFrame( 1 ).GetMethod( ).Name;
Debug.Assert( _lastName != null,
methodName,
"Last Name cannot be null" );
Debug.Assert( _lastName.Length > 0,
methodName,
"Last Name cannot be blank" );
Debug.Assert( _firstName != null,
methodName,
"First Name cannot be null" );
Debug.Assert( _firstName.Length > 0,
methodName,
"First Name cannot be blank" );
Trace.WriteLine( "Exiting CheckState for Person" );
#endif
}
使用#if和#endif編譯選項(pragmas)，你已經為你的發布版(release)編譯出了一個空方法。這個CheckState()方法會在所有的版本(debug和release)中調用。而在release中它什么也不做，但它要被調用。因此你還是得為例行公事的調用它而付出小部份代價。
不管怎樣，上面的實踐是可以正確工作的，但會導致一個只會出現在release中的細小BUG。下面的就是一個常見的錯誤，它會告訴你用條件編譯時會發生什么：
public void Func( )
{
string msg = null;
#if DEBUG
msg = GetDiagnostics( );
#endif
Console.WriteLine( msg );
}
這一切在Debug模式下工作的很正常，但在release下卻輸出的為空行。release模式很樂意給你輸出一個空行，然而這并不是你所期望的。傻眼了吧，但編譯器幫不了你什么。你的條件編譯塊里的基礎代碼確實是這樣邏輯。一些零散的#if/#endif塊使你的代碼在不同的編譯條件下很難得診斷(diagnose)。
C#有更好的選擇：這就是條件屬性。用條件屬性，你可以在指定的編譯環境下廢棄一個類的部份函數， 而這個環境可是某個變量是否被定義，或者是某個變量具有明確的值。這一功能最常見的用法就是使你的代碼具有調試時可用的聲明。.Net框架庫已經為你提供了了基本泛型功能。這個例子告訴你如何使用.net框架庫里的兼容性的調試功能，也告訴你條件屬性是如何工作的以及你在何時應該添加它：
當你建立了一個Person的對象時，你添加了一個方法來驗證對象的不變數據(invariants)：
private void CheckState( )
{
// Grab the name of the calling routine:
string methodName =
new StackTrace( ).GetFrame( 1 ).GetMethod( ).Name;
Trace.WriteLine( "Entering CheckState for Person:" );
Trace.Write( "\tcalled by " );
Trace.WriteLine( methodName );
Debug.Assert( _lastName != null,
methodName,
"Last Name cannot be null" );
Debug.Assert( _lastName.Length > 0,
methodName,
"Last Name cannot be blank" );
Debug.Assert( _firstName != null,
methodName,
"First Name cannot be null" );
Debug.Assert( _firstName.Length > 0,
methodName,
"First Name cannot be blank" );
Trace.WriteLine( "Exiting CheckState for Person" );
}
這這個方法上，你可能不必用到太多的庫函數，讓我簡化一下。這個StackTrace 類通過反射取得了調用方法的的名字。這樣的代價是昂貴的，但它確實很好的簡化了工作，例如生成程序流程的信息。這里，斷定了CheckState所調用的方法的名字。被判定(determining)的方法是System.Diagnostics.Debug類的一部份，或者是System.Diagnostics.Trace類的一部份。Degbug.Assert方法用來測試條件是否滿足，并在條件為false時會終止應用程序。剩下的參數定義了在斷言失敗后要打印的消息。Trace.WriteLine輸出診斷消息到調試控制臺。因此，這個方法會在Person對象不合法時輸出消息到調試控制臺，并終止應用程序。你可以把它做為一個先決條件或者后繼條件，在所有的公共方法或者屬性上調用這個方法。
public string LastName
{
get
{
CheckState( );
return _lastName;
}
set
{
CheckState( );
_lastName = value;
CheckState( );
}
}
在某人試圖給LastName賦空值或者null時，CheckState會在第一時間引發一個斷言。然后你就可以修正你的屬性設置器，來為LastName的參數做驗證。這就是你想要的。
但這樣的額外檢測存在于每次的例行任務里。你希望只在調試版中才做額外的驗證。這時候條件屬性就應運而生了：
[ Conditional( "DEBUG" ) ]
private void CheckState( )
{
// same code as above
}
Conditional屬性會告訴C#編譯器，這個方法只在編譯環境變量DEBUG有定義時才被調用。同時，Conditional屬性不會影響CheckState()函數生成的代碼，只是修改對函數的調用。如果DEBGU標記被定義，你可以得到這：
public string LastName
{
get
{
CheckState( );
return _lastName;
}
set
{
CheckState( );
_lastName = value;
CheckState( );
}
}
如果不是，你得到的就是這：
public string LastName
{
get
{
return _lastName;
}
set
{
_lastName = value;
}
}
不管環境變量的狀態如何，CheckState()的函數體是一樣的。這只是一個例子，它告訴你為什么要弄明白.Net里編譯和JIT之間的區別。不管DEBUG環境變量是否被定義，CheckState()方法總會被編譯且存在于程序集中。這或許看上去是低效的，但這只是占用一點硬盤空間，CheckState()函數不會被載入到內存，更不會被JITed(譯注：這里的JITed是指真正的編譯為機器代碼)，除非它被調用。它存在于程序集文件里并不是本質問題。這樣的策略是增強(程序的)可伸縮性的，并且這樣只是一點微不足道的性能開銷。你可以通過查看.Net框架庫中Debug類而得到更深入的理解。在任何一臺安裝了.Net框架庫的機器上，System.dll程序集包含了Debug類的所有方法的代碼。由環境變量在編譯時來決定是否讓由調用者來調用它們。
你同樣可以寫一個方法，讓它依懶于不只一個環境變量。當你應用多個環境變量來控制條件屬性時，他們時以or的形式并列的。例如，下面這個版本的CheckState會在DEBUG或者TRACE為真時被調用：
[ Conditional( "DEBUG" ),
Conditional( "TRACE" ) ]
private void CheckState( )
如果要產生一個and的并列條件屬性，你就要自己事先直接在代碼里使用預處理命令定義一個標記：
#if ( VAR1 && VAR2 )
#define BOTH
#endif
是的，為了創建一個依懶于前面多個環境變量的條件例程(conditional routine)，你不得不退到開始時使用的#if實踐中了。#if為我們產生一個新的標記，但避免在編譯選項內添加任何可運行的代碼。
Conditional屬性只能用在方法的實體上，另外，必須是一個返回類型為void的方法。你不能在方法內的某個代碼塊上使用Conditional，也不能在一個有返回值的方法上使用Conditional屬性。取而代之的是，你要細心構建一個條件方法，并在那些方法上廢棄條件屬性行為。你仍然要回顧一下那些具有條件屬性的方法，看它是否對對象的狀態具有副作用。但Conditional屬性在安置這些問題上比#if/#endif要好得多。在使用#if/#endif塊時，你很可能錯誤的移除了一個重要的方法調用或者一些配置。
前面的例子合用預先定義的DEBUG或者TRACE標記，但你可以用這個技巧，擴展到任何你想要的符號上。Conditional屬性可以由定義標記來靈活的控制。你可以在編譯命令行上定義，也可以在系統環境變量里定義，或者從源代碼的編譯選擇里定義。
使用Conditional屬性可以比使用#if/#endif生成更高效的IL代碼。在專門針對函數時，它更有優勢，它會強制你在條件代碼上使用更好的結構。編譯器使用Conditional屬性來幫助你避免因使用#if/#endif而產生的常見的錯誤。條件屬性比起預處理，它為你區分條件代碼提供了更好的支持。