C#條件編譯

本文轉載自查看原文 2022-01-25 10:57 815 Asp.Net Core

官方參考

網址：https://learn.microsoft.com/zh-CN/dotnet/csharp/language-reference/preprocessor-directives

=======================================================================================

C#利用條件編譯判斷.NET平台及版本的辦法，NET5標准符號清單及使用經驗

作者： zyl910

一、原初

.NET平台很早就提供了條件編譯的語法（#if）。
但是當時官方未制定標准的條件編譯符號（Conditional compilation symbols）的名稱，而是讓各程序自行約定。
由於早期只有“.NET Framework”這一種平台，且每次升級都是向下兼容的。沒有標准的標准的預處理器符號名，確實能減少復雜度。

二、混亂期

而到了.NET 4.0、VS2010 的時代，除了“.NET Framework”平台外，還多了“Silverlight”、“XBox”、“Windows Phone 7”等平台。
不久還出現了 PCL（Portable Class Libraries，可移植庫）這樣能在多個平台上的庫。且.NET 開始支持“WinRT/UWP”、“Android”、“iOS”等平台。
此時條件編譯就很重要了，可利用條件編譯對各平台做不同的處理。且有時為了避免編譯失敗或做降級處理，需要判斷平台的版本。

VS2015開始支持共享項目（Shared Project），能在代碼窗口隨時使用下拉框來切換平台版本。對條件編譯的需求越來越大了。

可是由於此時沒有統一的條件編譯符號名稱的約定，大家各自為政。導致代碼的可讀性、可移植性很差。
隨着開源代碼的傳播，符號名稱逐漸形成了一些共識。這一問題稍微有了好轉。

但還有一個更棘手的問題——C#里的條件編譯只能進行布爾（bool）檢查，不支持版本數值比較，導致判斷版本很費勁。

2.1 僅考慮“.NET Standard”平台時的條件判斷

例如有一段代碼，需要在“.NET Standard 1.3”以上環境運行。最開始可以這樣寫條件編譯的判斷：

#if NETSTANDARD1_3
    Console.WriteLine("Run on .NET Standard 1.3+");
#endif

注意“.NET Standard”是不斷升級的，目前最新是 2.1版。於是條件編譯的判斷需寫成這樣：

#if (NETSTANDARD1_3 || NETSTANDARD1_4 || NETSTANDARD1_5 || NETSTANDARD1_6 || NETSTANDARD2_0 || NETSTANDARD2_1)
    Console.WriteLine("Run on .NET Standard 1.3+");
#endif

若“.NET Standard”以后發布了新版本，那么這個條件編譯判斷得同步修改。

2.2 同時支持“.NET Standard”、“.NET Framework”平台

“.NET Framework”是兼容“.NET Standard”的，常用版本的對應關系是——

.NET Standard 1.3：.NET Framework 4.6
.NET Standard 1.4~2.0：.NET Framework 4.6.1
.NET Standard 2.1：.NET Framework 不支持

例如在“.NET Standard 1.3”上運行的代碼，是能在1.3對應的“.NET Framework 4.6”上運行的。於是條件編譯的判斷改寫成這樣：

#if (NETSTANDARD1_3 || NETSTANDARD1_4 || NETSTANDARD1_5 || NETSTANDARD1_6 || NETSTANDARD2_0 || NETSTANDARD2_1) || (NET46)
    Console.WriteLine("Run on .NET Standard 1.3+, .NET Framework 4.6+");
#endif

注意“.NET Framework”是不斷升級的，目前最新是 4.8版。於是條件編譯的判斷該寫成這樣：

#if (NETSTANDARD1_3 || NETSTANDARD1_4 || NETSTANDARD1_5 || NETSTANDARD1_6 || NETSTANDARD2_0 || NETSTANDARD2_1) || (NET46 || NET461 || NET462 || NET47 || NET471 || NET472 || NET48)
    Console.WriteLine("Run on .NET Standard 1.3+, .NET Framework 4.6+");
#endif

若“.NET Standard”、“.NET Framework”任一發布了新版本，那么這個條件編譯判斷得同步修改。
可見，進行多平台的版本判斷，條件編譯會寫的很冗長。而且隨着版本更新，得修改條件加新版本的符號，無法一勞永逸。

三、NET5的統一

到了NET5，官方終於制訂了標准的條件編譯符號。詳見官方文檔《SDK 樣式項目中的目標框架》中的“.NET 目標框架的預處理器符號的完整列表”： https://docs.microsoft.com/zh-cn/dotnet/standard/frameworks#how-to-specify-a-target-framework

.NET Framework: NETFRAMEWORK, NET48, NET472, NET471, NET47, NET462, NET461, NET46, NET452, NET451, NET45, NET40, NET35, NET20
.NET Standard: NETSTANDARD, NETSTANDARD2_1, NETSTANDARD2_0, NETSTANDARD1_6, NETSTANDARD1_5, NETSTANDARD1_4, NETSTANDARD1_3, NETSTANDARD1_2, NETSTANDARD1_1, NETSTANDARD1_0
.NET 5 及更高版本（和 .NET Core）: NET, NET6_0, NET5_0, NETCOREAPP, NETCOREAPP3_1, NETCOREAPP3_0, NETCOREAPP2_2, NETCOREAPP2_1, NETCOREAPP2_0, NETCOREAPP1_1, NETCOREAPP1_0

而且官方還貼心給出“_OR_GREATER”后綴的符號，用於簡化版本判斷。例如“NETSTANDARD1_3_OR_GREATER”表示“.NET Standard 1.3”或更高版本。

.NET Framework: NET48_OR_GREATER, NET472_OR_GREATER, NET471_OR_GREATER, NET47_OR_GREATER, NET462_OR_GREATER, NET461_OR_GREATER, NET46_OR_GREATER, NET452_OR_GREATER, NET451_OR_GREATER, NET45_OR_GREATER, NET40_OR_GREATER, NET35_OR_GREATER, NET20_OR_GREATER
.NET Standard: NETSTANDARD2_1_OR_GREATER, NETSTANDARD2_0_OR_GREATER, NETSTANDARD1_6_OR_GREATER, NETSTANDARD1_5_OR_GREATER, NETSTANDARD1_4_OR_GREATER, NETSTANDARD1_3_OR_GREATER, NETSTANDARD1_2_OR_GREATER, NETSTANDARD1_1_OR_GREATER, NETSTANDARD1_0_OR_GREATER
.NET 5 及更高版本（和 .NET Core）: NET6_0_OR_GREATER, NET5_0_OR_GREATER, NETCOREAPP3_1_OR_GREATER, NETCOREAPP3_0_OR_GREATER, NETCOREAPP2_2_OR_GREATER, NETCOREAPP2_1_OR_GREATER, NETCOREAPP2_0_OR_GREATER, NETCOREAPP1_1_OR_GREATER, NETCOREAPP1_0_OR_GREATER

有了這些標准符號后，剛才的條件編譯判斷便可以寫的很簡單了。

#if (NETSTANDARD1_3_OR_GREATER) || (NET46_OR_GREATER)
    Console.WriteLine("Run on .NET Standard 1.3+, .NET Framework 4.6+");
#endif

四、使用經驗

NET5雖然好，但是有一些舊項目短期內不能升級.NET版本、不能升級VS開發環境。且有時我們需開發支持舊平台的類庫。
此時VS不會像NET5那樣，自動為我們提供標准的條件編譯符號。

於是我們得自立更生，手工配置好條件編譯符號。可參考NET5標准的條件編譯符號，來進行配置，這樣能便於未來的平滑升級。
“_OR_GREATER”后綴的符號雖然好用，但對於手工配置條件編譯符號來說，太麻煩了。故可以不用。

為了簡化配置條件編譯符號的配置，建議僅配置當前版本的符號。例如——

對於“.NET Standard 1.3”的項目，僅需配置“NETSTANDARD;NETSTANDARD1_3”。
對於“.NET Framework 4.6”的項目，僅需配置“NETFRAMEWORK;NET46”。

由於舊版本的版本號已確定，僅是新版本的版本號無法確定。於是可以考慮反向進行條件編譯判斷，先判斷出不兼容的舊版本，這樣便能一勞永逸，即使版本升級也有效。
“.NET Framework”的歷史很長，若將所有的舊版本都列上，那會太冗長了。考慮到.NET 4.0時代才有多平台概念，故一般情況下，向前兼容只需做到.NET 4.0。有特殊需求時，才考慮支持更舊的版本。

根據這些經驗，剛才的條件編譯判斷，可寫成這樣：

#if (NETSTANDARD1_0 || NETSTANDARD1_1 || NETSTANDARD1_2) || (NET40 || NET45 || NET451 || NET452)
    // .NET Standard <=1.2, .NET Framework <=4.5.2
#else
    Console.WriteLine("Run on .NET Standard 1.3+, .NET Framework 4.6+");
#endif

（完）

出處：https://www.cnblogs.com/zyl910/p/cs_standard_conditional_compilation_symbols.html

=======================================================================================

C#條件編譯

本文導讀：

C#的預處理器指令從來不會轉化為可執行代碼的命令，但是會影響編譯過程的各個方面，常用的預處理器指令有#define、#undef、#if,#elif,#else和#endif等等，下面介紹C#中使用#define進行條件編譯的實例。

C#中條件編譯指令用於按條件包含或排除源文件中的某些部分。在Visual Studio中，會看到被排除的代碼顯示為灰色。

一、#define可以用來做什么

1、當計划發布兩個版本的代碼的時候。即基本版和擁有更多版本的企業版，就可以用到條件編譯指令；

2、例如同一個文件給silverlight、wpf、winform等使用，並且還考慮Debug和Release等，有大部分代碼是一樣的；

3、指定函數和屬性是否編譯到最終產品中去。

二、#define用法

語法：#define 名稱

注意：這里名稱取Debug，你也可以取其他名稱如Dragon

1 #define Debug

說明：

1、Debug可以看做是聲明的一個變量，但此變量沒有真正的值，存在時#if Debug結果為true，否則為false；

2、#define單獨用沒什么意義，一般是和#if或者Conditional特性結合使用；

3、#define必須定義在所有using命名空間前面；

4、Debug與DEBUG是不同的，C#區分大小寫。

三、#define條件編譯實例

方式一、使用#if

 1 #define Dragon
 2 using System;
 3 using System.Collections.Generic;
 4 using System.Linq;
 5 using System.Text;
 6 using System.Diagnostics;
 7 
 8 namespace ConditionalCompilation
 9 {
10     class Program
11     {
12         static void Main(string[] args)
13         {
14 #if Dragon
15             Console.WriteLine("Dragon is defined");
16 #else
17             Console.WriteLine("Dragon is not defined");
18 #endif
19             Console.ReadKey();
20         }
21     }
22 }

輸出結果如下：

如果注釋掉 //#define Dragon ，輸出結果為：

方式二、使用Conditional特性

我們可以將一些函數隔離出來，使得它們只有在定義了某些環境變量或者設置了某個值之后才能發揮作用，使用Conditional特性的隔離策略要比#if/#endif不容易出錯。

 1 #define Debug
 2 #define Trace
 3 #if (Debug && Trace)
 4 #define DebugAndTrace
 5 #endif
 6 using System;
 7 using System.Collections.Generic;
 8 using System.Linq;
 9 using System.Text;
10 using System.Diagnostics;
11 
12 namespace ConditionalCompilation
13 {
14     class Program
15     {
16         static void Main(string[] args)
17         {
18             Print0();
19             Print1();
20             Print2();
21             Print3();
22             Console.ReadKey();
23         }
24 
25         [Conditional("DEBUG")]
26         static void Print0()
27         {
28             Console.WriteLine("DEBUG is defined");
29         }
30 
31         [Conditional("Debug")]
32         static void Print1()
33         {
34             Console.WriteLine("Debug is defined");
35         }
36 
37         //定義了Debug或者Trace后才會執行此方法
38         //或者的關系
39         [Conditional("Debug"), Conditional("Trace")]
40         static void Print2()
41         {
42             Console.WriteLine("Debug or Trace is defined");
43         }
44 
45         //只有定義了Debug和Trace后才會執行此方法
46         //並且的關系
47         [Conditional("DebugAndTrace")]
48         static void Print3()
49         {
50             Console.WriteLine("Debug and Trace is defined");
51         }
52     }
53 }

輸出結果如下：

說明：

1、代碼中沒有定義DEBUG，卻輸出了DEBUG，是因為DEBUG版本，自動定義了DEBUG。“項目——右鍵——屬性——生成選項卡——常規欄”下的定義 DEBUG 常量(U)前面的復選框被選中。當然你可以去掉其選中狀態，這樣就不會輸出DEBUG了。

2、如果Debug和Trace均沒有定義，則不會輸出Debug or Trace；只有Debug和Trace均定義了，才會輸出Debug and Trace。

3、可以給Conditional增加多個屬性如示例代碼 [Conditional("Debug"), Conditional("Trace")] ，不過多個屬性之間的關系是或的關系，即“Debug”或者“Trace”任意一個被定義了，那么對應方法就會被執行。

4、如果需要增加多個與的屬性，直接用Conditional是無法實現的，需要借助#if/#endif間接來完成，如示例代碼中的組合操作

環境變量(或條件編譯符號)的設置方法有三：

1)用#define定義以及#undef取消定義，在所有using命名空間前面定義；

2)用編譯器命令行選項(例如，/define:DEBUG)，在“項目——右鍵——屬性——生成選項卡——常規欄”下的條件編譯符號(Y)中設置(如果多個，可以用英文逗號隔開)。DEBUG版本下，系統默認設置了DEBUG和TRACE；

3)用操作系統外殼程序中的環境變量(例如，set DEBUG=1)。

出處：https://www.cnblogs.com/xietianjiao/p/12373281.html

=======================================================================================

讀 .NET Core中的文件操作、讀取文件、Debug/Trace 類、Conditional條件編譯、CLS

1，文件操作
2，讀取文件
3，Debug 、Trace類
4，條件編譯
5，MethodImpl 特性
5，CLSCompliantAttribute
6，必要時自定義類型別名

1，文件操作

2，Debug、Trace類

3，條件編譯

4，MethodImpl 特性

5，CLSComplianAttribute

6，必要時自定義類型別名

最近在閱讀 .NET Core Runtime 的源碼，參考大佬的代碼，學習編寫技巧和提高代碼水平。學習過程中將學習心得和值得應用到項目中的代碼片段記錄下來，供日后查閱。

1，文件操作

這段代碼在 System.Private.CoreLib 下，對 System.IO.File 中的代碼進行精簡，供 CLR 使用。

當使用文件時，要提前判斷文件路徑是否存在，日常項目中要使用到文件的地方應該不少，可以統一一個判斷文件是否存在的方法：

        public static bool Exists(string? path)
        {
            try
            {
                // 可以將 string? 改成 string
                if (path == null)
                    return false;
                if (path.Length == 0)
                    return false;

                path = Path.GetFullPath(path);

                // After normalizing, check whether path ends in directory separator.
                // Otherwise, FillAttributeInfo removes it and we may return a false positive.
                // GetFullPath should never return null
                Debug.Assert(path != null, "File.Exists: GetFullPath returned null");
                if (path.Length > 0 && PathInternal.IsDirectorySeparator(path[^1]))
                {
                    return false;
                }

                return InternalExists(path);
            }
            catch (ArgumentException) { }
            catch (NotSupportedException) { } // Security can throw this on ":"
            catch (SecurityException) { }
            catch (IOException) { }
            catch (UnauthorizedAccessException) { }

            return false;
        }

建議項目中對路徑進行最終處理的時候，都轉換為絕對路徑：

Path.GetFullPath(path)

當然，相對路徑會被 .NET 正確識別，但是對於運維排查問題和各方面考慮，絕對路徑容易定位具體位置和排錯。

在編寫代碼時，使用相對路徑，不要寫死，提高靈活性；在運行階段將其轉為絕對路徑；

上面的 NotSupportedException 等異常是操作文件中可能出現的各種異常情況，對於跨平台應用來說，這些異常可能都是很常見的，提前將其異常類型識別處理，可以優化文件處理邏輯以及便於篩查處理錯誤。

2，讀取文件

這段代碼在 System.Private.CoreLib 中。

有個讀取文件轉換為 byte[] 的方法如下：

        public static byte[] ReadAllBytes(string path)
        {
            // bufferSize == 1 used to avoid unnecessary buffer in FileStream
            using (FileStream fs = new FileStream(path, FileMode.Open, FileAccess.Read, FileShare.Read, bufferSize: 1))
            {
                long fileLength = fs.Length;
                if (fileLength > int.MaxValue)
                    throw new IOException(SR.IO_FileTooLong2GB);

                int index = 0;
                int count = (int)fileLength;
                byte[] bytes = new byte[count];
                while (count > 0)
                {
                    int n = fs.Read(bytes, index, count);
                    if (n == 0)
                        throw Error.GetEndOfFile();
                    index += n;
                    count -= n;
                }
                return bytes;
            }
        }

可以看到 FileStream 的使用，如果單純是讀取文件內容，可以參考里面的代碼：

        FileStream fs = new FileStream(path, 
                                       FileMode.Open, 
                                       FileAccess.Read, 
                                       FileShare.Read, 
                                       bufferSize: 1)

上面的代碼同樣也存在 File.ReadAllBytes 與之對應， File.ReadAllBytes 內部是使用 InternalReadAllBytes 來處理文檔讀取：

        private static byte[] InternalReadAllBytes(String path, bool checkHost)
        {
            byte[] bytes;
            // 此 FileStream 的構造函數不是 public ，開發者不能使用
            using(FileStream fs = new FileStream(path, FileMode.Open, FileAccess.Read, FileShare.Read, 
                FileStream.DefaultBufferSize, FileOptions.None, Path.GetFileName(path), false, false, checkHost)) {
                // Do a blocking read
                int index = 0;
                long fileLength = fs.Length;
                if (fileLength > Int32.MaxValue)
                    throw new IOException(Environment.GetResourceString("IO.IO_FileTooLong2GB"));
                int count = (int) fileLength;
                bytes = new byte[count];
                while(count > 0) {
                    int n = fs.Read(bytes, index, count);
                    if (n == 0)
                        __Error.EndOfFile();
                    index += n;
                    count -= n;
                }
            }
            return bytes;
        }

這段說明我們可以放心使用 File 靜態類中的函數，因為里面已經處理好一些邏輯了，並且自動釋放文件。

如果我們手動 new FileStream ，則要判斷一些情況，以免使用時報錯，最好參考一下上面的代碼。

.NET 文件流緩存大小默認是 4096 字節：

internal const int DefaultBufferSize = 4096;

這段代碼在 File 類中定義，開發者不能設置緩存塊的大小，大多數情況下，4k 是最優的塊大小。

ReadAllBytes 的文件大小上限是 2 GB。

3，Debug 、Trace類

這兩個類的命名空間為 System.Diagnostics，Debug 、Trace 提供一組有助於調試代碼的方法和屬性。

Debug 中的所有函數都不會在 Release 中有效，並且所有輸出流不會在控制台顯示，必須注冊偵聽器才能讀取這些流。

Debug 可以打印調試信息並使用斷言檢查邏輯，使代碼更可靠，而不會影響發運產品的性能和代碼大小。

這類輸出方法有 Write 、WriteLine 、 WriteIf 和 WriteLineIf 等，這里輸出不會直接打印到控制台。

如需將調試信息打印到控制台，可以注冊偵聽器：

ConsoleTraceListener console = new ConsoleTraceListener();
Trace.Listeners.Add(console);

注意， .NET Core 2.x 以上 Debug 沒有 Listeners ，因為 Debug 使用的是 Trace 的偵聽器。

我們可以給 Trace.Listeners 注冊偵聽器，這樣相對於 Debug 等效設置偵聽器。

        Trace.Listeners.Add(new TextWriterTraceListener(Console.Out));
        Debug.WriteLine("aa");

.NET Core 中的監聽器都繼承了 TraceListener，如 TextWriterTraceListener、ConsoleTraceListener、DefaultTraceListener。

如果需要輸出到文件中，可以自行繼承 TextWriterTraceListener ，編寫文件流輸出，也可以使用 DelimitedListTraceListener。

示例：

TraceListener listener = new DelimitedListTraceListener(@"C:\debugfile.txt");

        // Add listener.
        Debug.Listeners.Add(listener);

        // Write and flush.
        Debug.WriteLine("Welcome");

處理上述方法輸出控制台，也可以使用

ConsoleTraceListener console=...
...Listeners.Add(console);

// 等效於
var console = new TextWriterTraceListener(Console.Out)

為了格式化輸出流，可以使用一下屬性控制排版：

屬性	說明
AutoFlush	獲取或設置一個值，通過該值指示每次寫入后是否應在 Flush() 上調用 Listeners。
IndentLevel	獲取或設置縮進級別。
IndentSize	獲取或設置縮進的空格數。

        // 1.
        Debug.WriteLine("One");

        // Indent and then unindent after writing.
        Debug.Indent();
        Debug.WriteLine("Two");
        Debug.WriteLine("Three");
        Debug.Unindent();

        // End.
        Debug.WriteLine("Four");

        // Sleep.
        System.Threading.Thread.Sleep(10000);

One
 Two Three Four

.Assert() 方法對我們調試程序很有幫助，Assert 向開發人員發送一個強消息。在 IDE 中，斷言會中斷程序的正常操作，但不會終止應用程序。

.Assert() 的最直觀效果是輸出程序的斷言位置。

        Trace.Listeners.Add(new TextWriterTraceListener(Console.Out));
        int value = -1;
        // A.
        // If value is ever -1, then a dialog will be shown.
        Debug.Assert(value != -1, "Value must never be -1.");

        // B.
        // If you want to only write a line, use WriteLineIf.
        Debug.WriteLineIf(value == -1, "Value is -1.");

---- DEBUG ASSERTION FAILED ----
---- Assert Short Message ----
Value must never be -1.
---- Assert Long Message ----

   at Program.Main(String[] args) in ...Program.cs:line 12

Value is -1.

Debug.Prinf() 也可以輸出信息，它跟 C 語言的 printf 函數行為一致，將后跟行結束符的消息寫入，默認行終止符為回車符后跟一個換行符。

在 IDE 中運行程序時，使用 Debug.Assert()、Trace.Assert() 等方法，條件為 false 時，IDE 會斷言，這相當於條件斷點。

在非 IDE 環境下，程序會輸出一些信息，但不會有中斷效果。

        Trace.Listeners.Add(new TextWriterTraceListener(Console.Out));
        Trace.Assert(false);

Process terminated. Assertion Failed
   at Program.Main(String[] args) in C:\ConsoleApp4\Program.cs:line 44

個人認為，可以將 Debug、Trace 引入項目中，與日志組件配合使用。Debug、Trace 用於記錄程序運行的診斷信息，便於日后排查程序問題；日志用於記錄業務過程，數據信息等。

.Assert() 的原理，在 true 時什么都不做；在 false 時調用 Fail 函數；如果你不注冊偵聽器的話，默認也沒事可做。

.Assert() 唯一可做的事情是等條件為 false 時，執行 Fail 方法，當然我們也可以手動直接調用 Fail 方法，Fail 的代碼如下：

public static void Fail(string message) {
            if (UseGlobalLock) {
                lock (critSec) {
                    foreach (TraceListener listener in Listeners) {
                        listener.Fail(message);
                        if (AutoFlush) listener.Flush();
                    }            
                }
            }
            else {
                foreach (TraceListener listener in Listeners) {
                    if (!listener.IsThreadSafe) {
                        lock (listener) {
                            listener.Fail(message);
                            if (AutoFlush) listener.Flush();
                        }
                    }
                    else {
                        listener.Fail(message);
                        if (AutoFlush) listener.Flush();
                    }
                }            
            }
        }

4，條件編譯

#if 條件編譯會隱藏非條件(#else if)代碼，我們開發中很可能會忽略掉這部分代碼，當我們切換條件常量到這部分代碼時，很可能因為各種原因導致報錯。

如果使用特性進行條件編譯標記，在開發過程中就可以留意到這部分代碼。

[Conditional("DEBUG")]

例如，當使用修改所有引用-修改一個類成員變量或者靜態變量名稱時，#if 非條件中的代碼不會被修改，因為這部分代碼“無效”，而且使用 [Conditional("DEBUG")] 的代碼則跟條件無關，會被同步修改。

Conditional 特性標記的方法等，在開發過程中保持有效，當在編譯時可能被排除。

代碼片段只能使用 #if 了，如果是單個方法，則可以使用 Conditional 。

5，MethodImpl 特性

此特性在 System.Runtime.CompilerServices 命名空間中，指定如何實現方法的詳細信息。

內聯函數使用方法可參考 https://www.whuanle.cn/archives/995

MethodImpl 特性可以影響 JIT 編譯器的行為。

無法使用 MemberInfo.GetCustomAttributes 來獲取此特性的信息，即不能通過獲取特性的方法獲取跟 MethodImpl 有關的信息(反射)，只能調用 MethodInfo.GetMethodImplementationFlags() 或 ConstructorInfo.GetMethodImplementationFlags () 來檢索。

MethodImpl 可以在方法以及構造函數上使用。

MethodImplOptions 用於設置編譯行為，枚舉值可組合使用，其枚舉說明如下：

枚舉	枚舉值	說明
AggressiveInlining	256	如可能應將該方法進行內聯。
AggressiveOptimization	512	此方法包含一個熱路徑，且應進行優化。
ForwardRef	16	已聲明該方法，但在其他位置提供實現。
InternalCall	4096	該調用為內部調用，也就是說它調用了在公共語言運行時中實現的方法。
NoInlining	8	該方法不能為內聯方法。內聯是一種優化方式，通過該方式將方法調用替換為方法體。
NoOptimization	64	調試可能的代碼生成問題時，該方法不由實時 (JIT) 編譯器或本機代碼生成優化（請參閱 Ngen.exe）。
PreserveSig	128	完全按照聲明導出方法簽名。
Synchronized	32	該方法一次性只能在一個線程上執行。靜態方法在類型上鎖定，而實例方法在實例上鎖定。只有一個線程可在任意實例函數中執行，且只有一個線程可在任意類的靜態函數中執行。
Unmanaged	4	此方法在非托管的代碼中實現。

Synchronized 修飾的方法可以避免多線程中的一些問題，但是不建議對公共類型使用鎖定實例或類型上的鎖定，因為 Synchronized 可以對非自己的代碼的公共類型和實例進行鎖定。這可能會導致死鎖或其他同步問題。

意思是說，如果共享的成員已經設置了鎖，那么不應該再在 Synchronized 方法中使用，這樣雙重鎖定容易導致死鎖以及其他問題。

5，CLSCompliantAttribute

指示程序元素是否符合公共語言規范 (CLS)。

CLS規范可參考：

https://docs.microsoft.com/en-us/dotnet/standard/language-independence

https://www.ecma-international.org/publications/standards/Ecma-335.htm

全局開啟方法：

程序目錄下添加一個 AssemblyAttribytes.cs 文件，或者打開 obj 目錄，找到 AssemblyAttributes.cs 結尾的文件，如 .NETCoreApp,Version=v3.1.AssemblyAttributes.cs，添加：

using System;	// 這行已經有的話不要加
[assembly: CLSCompliant(true)]

之后就可以在代碼中使用 [CLSCompliant(true)] 特性。

局部開啟：

也可以放在類等成員上使用：

[assembly: CLSCompliant(true)]

您可以將特性應用於 CLSCompliantAttribute 下列程序元素：程序集、模塊、類、結構、枚舉、構造函數、方法、屬性、字段、事件、接口、委托、參數和返回值。但是，CLS 遵從性的概念僅適用於程序集、模塊、類型和類型的成員。

程序編譯時默認不會檢查代碼是否符合 CLS 要求，但是如果你的可以是公開的(代碼共享、Nuget 發布等)，則建議使用使用 [assembly: CLSCompliant(true)] ，指明你的庫符合 CLS 要求。

在團隊開發中以及內部共享代碼時，高質量的代碼尤為重要，所以有必要使用工具檢查代碼，如 roslyn 靜態分析、sonar 掃描等，也可以使用上面的特性，自動使用 CLS 檢查。

CLS 部分要求：

無符號類型不應成為該類的公共接口的一部分(私有成員可以使用)，例如 UInt32 這些屬於 C# 的類型，但不是 CLS “標准” 中的。
指針等不安全類型不能與公共成員一起使用，就是公有方法中都不應該使用 unsafe 代碼。(私有成員可以使用)。
類名和成員名不應重名。雖然 C# 中區分大小寫，但是 CLS 不建議同名非重載函數，例如 MYTEST 跟 Mytest。
只能重載屬性和方法，不應重載運算符。重載運算符容易導致調用者不知情時出現程序錯誤，並且重載運算符要排查問題十分困難。

我們可以編譯以下代碼，嘗試使用 CLSCompliant ：

[assembly: CLSCompliant(true)]
[CLSCompliant(true)]
public class Test
{
    public void MyMethod()
    {
    }
    public void MYMETHOD()
    {
    }
}

IDE 中會警告：warning CS3005: 僅大小寫不同的標識符“Test.MYMETHOD()”不符合 CLS，編譯時也會提示 Warn。當然，不會阻止編譯，也不會影響程序運行。

總之，如果要標記一個程序集 CLS 規范，可以使用 [assembly: CLSCompliant(true)] 特性。

[CLSCompliant(true)] 特性指示這個元素符合 CLS 規范，這時編譯器或者 IDE 會檢查你的代碼，檢查是否真的符合規范。

如果偏偏要寫不符合規范的代碼，則可以使用 [CLSCompliant(false)]。

6，必要時自定義類型別名

C# 也可以定義類型別名。

using intbyte = System.Int32;
using intkb = System.Int32;
using intmb = System.Int32;
using intgb = System.Int32;
using inttb = System.Int32;

        byte[] fileByte = File.ReadAllBytes("./666.txt");
        intmb size = fileByte.Length / 1024;

一些情況下，使用別名可以提高代碼可讀性。真實項目不要使用以上代碼，我只是寫個示例，這並不是合適的應用場景。

今天學習 Runtime 的代碼就到這里為止。

出處：https://www.cnblogs.com/whuanle/p/14141213.html

免責聲明！

本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。

猜您在找 C#條件編譯 C# 通過條件編譯來控制不同版本 C語言中的條件編譯 C#-#define條件編譯 C# 條件與&&與條件或||的使用總結 C# 動態編譯 C#是如何編譯的? C# 好代碼學習筆記(1)：文件操作、讀取文件、Debug/Trace 類、Conditional條件編譯、CLS C#利用條件編譯判斷.NET平台及版本的辦法，NET5標准符號清單及使用經驗 [C#] Linq 動態條件查詢