整合營銷服務商
電腦端+手機端+微信端=數(shù)據(jù)同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數(shù)據(jù)同步管理
免費咨詢熱線：
.NET Core 中，WebUtility 和 HttpUtility 都是用于編碼和解碼 HTML、URL 和 MIME 字符串的工具類，但它們有一些區(qū)別：
命名空間不同
WebUtility 在命名空間 System.Net.WebUtility 中，而 HttpUtility 在命名空間 System.Web 中。
支持的方法不同
WebUtility 只支持編碼和解碼 HTML 實體和 URL 字符串，而 HttpUtility 支持編碼和解碼 HTML 實體、URL 字符串和 MIME 字符串。
處理未知字符的方式不同
WebUtility 對于未知字符使用默認的轉(zhuǎn)義實體，而 HttpUtility 具有一個參數(shù)指定未知字符的處理方式，可以選擇使用默認的轉(zhuǎn)義實體或者不進行轉(zhuǎn)義。
.NET Core 支持的版本不同
WebUtility 是從 .NET Framework 4 開始引入的，而 HttpUtility 是從 .NET Framework 1.1 開始引入的。在 .NET Core 中，WebUtility 是支持的，而 HttpUtility 則不支持。
因此，如果您正在使用 .NET Core，應該使用 WebUtility 進行 HTML 實體和 URL 字符串的編碼和解碼。如果您在使用 .NET Framework，則可以使用 WebUtility 或 HttpUtility 來編碼和解碼 HTML 實體、URL 字符串和 MIME 字符串。
么是.NET？什么是.NET Framework?本文將從上往下，循序漸進的介紹一系列相關(guān).NET的概念，先從類型系統(tǒng)開始講起，我將通過跨語言操作這個例子來逐漸引入一系列.NET的相關(guān)概念，這主要包括：CLS、CTS(CLI)、FCL、Windows下CLR的相關(guān)核心組成、Windows下托管程序運行概念、什么是.NET Framework，.NET Core，.NET Standard及一些VS編譯器相關(guān)雜項和相關(guān)閱讀鏈接。完整的從上讀到下則你可以理解個大概的.NET體系。
文章是我一字一字親手碼出來的，每天下班用休息時間寫一點，持續(xù)了二十來天。且對于文章上下銜接、概念引入花了很多心思，致力讓很多概念在本文中顯得通俗。但畢竟.NET系統(tǒng)很龐大，本文篇幅有限，所以在部分小節(jié)中我會給出延伸閱讀的鏈接，在文章結(jié)尾我給出了一些小的建議，希望能對需要幫助的人帶來幫助，如果想與我交流可以文章留言或者加.NET技術(shù)交流群：166843154
.NET和C#是什么關(guān)系
語言，是人們進行溝通表達的主要方式。編程語言，是人與機器溝通的表達方式。不同的編程語言，其側(cè)重點不同。有的編程語言是為了科學計算而開發(fā)的，所以其語法和功能更偏向于函數(shù)式思想。有些則是為了開發(fā)應用程序而創(chuàng)立的，所以其語法和功能更為均衡全面。
微軟公司是全球最大的電腦軟件提供商，為了占據(jù)開發(fā)者市場，進而在2002年推出了Visual Studio(簡稱VS，是微軟提供給開發(fā)者的工具集) .NET 1.0版本的開發(fā)者平臺。而為了吸引更多的開發(fā)者涌入平臺，微軟還在2002年宣布推出一個特性強大并且與.NET平臺無縫集成的編程語言，即C# 1.0正式版。
只要是.NET支持的編程語言，開發(fā)者就可以通過.NET平臺提供的工具服務和框架支持便捷的開發(fā)應用程序。
C#就是為宣傳.NET而創(chuàng)立的，它直接集成于Visual Studio .NET中，VB也在.NET 1.0發(fā)布后對其進行支持， 所以這兩門語言與.NET平臺耦合度很高，并且.NET上的技術(shù)大多都是以C#編程語言為示例，所以經(jīng)常就.NET和C#混為一談(實質(zhì)上它們是相輔相成的兩個概念)。
而作為一個開發(fā)者平臺，它不僅僅是包含開發(fā)環(huán)境、技術(shù)框架、社區(qū)論壇、服務支持等，它還強調(diào)了平臺的跨語言、跨平臺編程的兩個特性。
跨語言和跨平臺是什么
跨語言：即只要是面向.NET平臺的編程語言((C#、Visual Basic、C++/CLI、Eiffel、F#、IronPython、IronRuby、PowerBuilder、Visual COBOL 以及 Windows PowerShell))，用其中一種語言編寫的類型可以無縫地用在另一種語言編寫的應用程序中的互操作性。
跨平臺：一次編譯，不需要任何代碼修改，應用程序就可以運行在任意有.NET框架實現(xiàn)的平臺上，即代碼不依賴于操作系統(tǒng)，也不依賴硬件環(huán)境。
什么是跨語言互操作，什么是CLS
每門語言在最初被設計時都有其在功能和語法上的定位，讓不同的人使用擅長的語言去干合適的事，這在團隊協(xié)作時尤為重要。
.NET平臺上的跨語言是通過CLS這個概念來實現(xiàn)的，接下來我就以C#和VB來演示 什么是.NET中的跨語言互操作性。
通俗來說，雖然c#和vb是兩個不同的語言，但此處c#寫的類可以在vb中當做自家寫的類一樣正常使用。
比如我在vb中寫了一個針對String的首字母大寫的擴展方法，將其編譯后的dll引用至C#項目中。
在C#項目中，可以像自身代碼一樣正常使用來自vb這個dll的擴展方法。
現(xiàn)在有那么多面向?qū)ο笳Z言，但不是所有編程語言都能這樣直接互操作使用，而.NET平臺支持的C#和VB之所以能這樣無縫銜接，先讀而后知，后文將會介紹緣由。不過雖然.NET平臺提供了這樣一個互操作的特性，但終究語言是不一樣的，每個語言有其特色和差異處，在相互操作的時候就會難免遇到一些例外情況。
比如我在C#中定義了一個基類，類里面包含一個公開的指針類型的成員，我想在vb中繼承這個類，并訪問這個公開的成員。
但是vb語言因為其定位不需要指針，所以并沒有C#中如int*這樣的指針類型，所以在vb中訪問一個該語言不支持的類型會報錯的，會提示：字段的類型不受支持。
再比如，C#語言中，對類名是區(qū)分大小寫的，我在C#中定義了兩個類，一個叫BaseBusiness，另一個叫baseBusiness。我在vb中去繼承這個BaseBusiness類。
如圖，在vb中訪問這個類會報錯的，報:"BaseBusiness"不明確，這是因為在vb中對類名是不區(qū)分大小寫的。在vb中，它認為它同時訪問了兩個一模一樣的類，所以按照vb的規(guī)則這是不合理的。那么為了在vb調(diào)用c#的程序集中避免這些因語言的差異性而導致的錯誤，在編寫c#代碼的時候 就應該提前知道vb中的這些規(guī)則，來應付式的開發(fā)。
但是，如果我想不僅僅局限于C#和VB，我還想我編寫的代碼在.Net平臺上通用的話，那么我還必須得知道.NET平臺支持的每一種語言和我編寫代碼所使用的語言的差異，從而在編寫代碼中避免這些。
這幾年編程語言層出不窮，在將來.NET可能還會支持更多的語言，如果說對一個開發(fā)者而言掌握所有語言的差異處這是不現(xiàn)實的，所以.NET專門為此參考每種語言并找出了語言間的共性，然后定義了一組規(guī)則，開發(fā)者都遵守這個規(guī)則來編碼，那么代碼就能被任意.NET平臺支持的語言所通用。
而與其說是規(guī)則，不如說它是一組語言互操作的標準規(guī)范，它就是公共語言規(guī)范 - Common Language Specification ,簡稱CLS
CLS從類型、命名、事件、屬性、數(shù)組等方面對語言進行了共性的定義及規(guī)范。這些東西被提交給歐洲計算機制造聯(lián)合會ECMA，稱為：共同語言基礎設施。
就以類型而言，CLS定義了在C#語言中符合規(guī)范的類型和不符合的有：
當然，就編碼角度而言，我們不是必須要看那些詳略的文檔。為了方便開發(fā)者開發(fā)，.NET提供了一個特性，名叫：CLSCompliantAttribute，代碼被CLSCompliantAttribute標記后，如果你寫的代碼不符合CLS規(guī)范的話，編譯器就會給你一條警告。
值得一提的是，CLS規(guī)則只是面向那些公開可被其它程序集訪問的成員，如public、繼承的protected，對于該程序集的內(nèi)部成員如Private、internal則不會執(zhí)行該檢測規(guī)則。也就是說，所適應的CLS遵從性規(guī)則，僅是那些公開的成員，而非私有實現(xiàn)。
那么有沒有那種特殊情況，比如我通過反射技術(shù)來訪問該程序集中，當前語言并不擁有的類型時會發(fā)生什么情況呢？
答案是可以嘗試的，如用vb反射訪問c#中的char*指針類型，即使vb中沒有char*這種等價的指針類型，但mscorlib提供了針對指針類型的 Pointer 包裝類供其訪問，可以從運行時類攜帶的類型名稱看到其原本的類型名。
可以看到，該類中的元素是不符合CLS規(guī)范的。
CLS異常
提到特殊情況，還要說的一點就是異常處理。.NET框架組成中定義了異常類型系統(tǒng)，在編譯器角度，所有catch捕獲的異常都必須繼承自System.Exception，如果你要調(diào)用一個 由不遵循此規(guī)范的語言 拋出其它類型的異常對象(C++允許拋出任何類型的異常，如C#調(diào)用C++代碼，C++拋出一個string類型的異常)，在C#2.0之前Catch(Exception)是捕捉不了的，但之后的版本可以。
在后續(xù)版本中，微軟提供了System.Runtime.CompilerServices.RuntimeWrappedException異常類，將那些不符合CLS的包含Exception的對象封裝起來。并且可以通過RuntimeCompatibilityAttribute特性來過濾這些異常。
RuntimeWrappedException ：https://docs.microsoft.com/zh-cn/dotnet/api/system.runtime.compilerservices.runtimewrappedexception?view=netframework-4.7.2
那么，這個段落總結(jié)一下，什么是CLS呢？
在面向.NET開發(fā)中，編寫跨語言組件時所遵循的那些共性，那些規(guī)范就叫做 Common Langrage Specification簡稱 CLS，公共語言規(guī)范
什么是CTS？
如果理解了什么是CLS的話，那么你將很輕松理解什么是CTS。
假設你已經(jīng)圍繞著封裝 繼承 多態(tài) 這3個特性設計出了多款面向?qū)ο蟮恼Z言，你發(fā)現(xiàn)大家都是面向?qū)ο螅寄芎芎玫膶F(xiàn)實中的對象模型表達出來。除了語法和功能擅長不同，語言的定義和設計結(jié)構(gòu)其實都差不多一回事。
比如，現(xiàn)實中你看到了一輛小汽車，這輛車里坐著兩個人，那么如何用這門語言來表達這樣的一個概念和場面？
首先要為這門語言橫向定義一個“類型”的概念。接下來在程序中就可以這樣表示：有一個汽車類型，有一個人類型，在一個汽車類型的對象內(nèi)包含著兩個人類型的對象，因為要表達出這個模型，你又引入了“對象”的概念 。而現(xiàn)在，你又看到，汽車里面的人做出了開車的這樣一個動作，由此你又引入了“動作指令”這樣一個概念。
接著，你又恍然大悟總結(jié)出一個定理，無論是什么樣的“類型”，都只會存在這樣一個特征，即活著的 帶生命特征的(如人) 和 死的 沒有生命特征的(如汽車) 這兩者中的一個。最后，隨著思想模型的成熟，你發(fā)現(xiàn)，這個“類型”就相當于一個富有主體特征的一組指令的集合。
好，然后你開始照葫蘆畫瓢。你參考其它程序語言，你發(fā)現(xiàn)大家都是用class來表示類的含義，用struct表示結(jié)構(gòu)的含義，用new來表示 新建一個對象的含義，于是，你對這部分功能的語法也使用class和new關(guān)鍵字來表示。然后你又發(fā)現(xiàn)，他們還用很多關(guān)鍵字來更豐富的表示這些現(xiàn)實模型，比如override、virtual等。于是，在不斷的思想升級和借鑒后，你對這個設計語言過程中思想的變化仔細分析，對這套語言體系給抽象歸納，最終總結(jié)出一套體系。
于是你對其它人這樣說，我總結(jié)出了一門語言很多必要的東西如兩種主要類別：值類別和引用類別，五個主要類型：類、接口、委托、結(jié)構(gòu)、枚舉，我還規(guī)定了，一個類型可以包含字段、屬性、方法、事件等成員，我還指定了每種類型的可見性規(guī)則和類型成員的訪問規(guī)則，等等等等，只要按照我這個體系來設計語言，設計出來的語言它能夠擁有很多不錯的特性，比如跨語言，跨平臺等，C#和VB.net之所以能夠這樣就是因為這兩門語言的設計符合我這個體系。
那么，什么是CTS呢？
當你需要設計面向.Net的語言時所需要遵循一個體系(.Net平臺下的語言都支持的一個體系)這個體系就是CTS（Common Type System 公共類型系統(tǒng)），它包括但不限于：
上文的CLS是CTS（Common Type System 公共類型系統(tǒng)）這個體系中的子集。
一個編程語言，如果它能夠支持CTS，那么我們就稱它為面向.NET平臺的語言。
官方CTS介紹： https://docs.microsoft.com/zh-cn/dotnet/standard/common-type-system
微軟已經(jīng)將CTS和.NET的一些其它組件，提交給ECMA以成為公開的標準，最后形成的標準稱為CLI（Common Language Infrastructure）公共語言基礎結(jié)構(gòu)。
所以有的時候你見到的書籍或文章有的只提起CTS，有的只提起CLI，請不要奇怪，你可以寬泛的把他們理解成一個意思，CLI是微軟將CTS等內(nèi)容提交給國際組織計算機制造聯(lián)合會ECMA的一個工業(yè)標準。
什么是類庫？
在CTS中有一條就是要求基元數(shù)據(jù)類型的類庫。我們先搞清什么是類庫？類庫就是類的邏輯集合，你開發(fā)工作中你用過或自己編寫過很多工具類，比如搞Web的經(jīng)常要用到的 JsonHelper、XmlHelper、HttpHelper等等，這些類通常都會在命名為Tool、Utility等這樣的項目中。 像這些類的集合我們可以在邏輯上稱之為 "類庫"，比如這些Helper我們統(tǒng)稱為工具類庫。
什么是基礎類庫BCL？
當你通過VS創(chuàng)建一個項目后，你這個項目就已經(jīng)引用好了通過.NET下的語言編寫好的一些類庫。比如控制臺中你直接就可以用ConSole類來輸出信息，或者using System.IO 即可通過File類對文件進行讀取或?qū)懭氩僮鳎@些類都是微軟幫你寫好的，不用你自己去編寫，它幫你編寫了一個面向.NET的開發(fā)語言中使用的基本的功能，這部分類，我們稱之為BCL（Base Class Library）， 基礎類庫，它們大多都包含在System命名空間下。
基礎類庫BCL包含：基本數(shù)據(jù)類型，文件操作，集合，自定義屬性，格式設置，安全屬性，I/O流，字符串操作，事件日志等的類型
什么是框架類庫FCL？
有關(guān)BCL的就不在此一一類舉。.NET之大，發(fā)展至今，由微軟幫助開發(fā)人員編寫的類庫越來越多，這讓我們開發(fā)人員開發(fā)更加容易。由微軟開發(fā)的類庫統(tǒng)稱為：FCL，F(xiàn)ramework Class Library ，.NET框架類庫，我上述所表達的BCL就是FCL中的一個基礎部分，F(xiàn)CL中大部分類都是通過C#來編寫的。
在FCL中，除了最基礎的那部分BCL之外，還包含我們常見的 如 ： 用于網(wǎng)站開發(fā)技術(shù)的 ASP.NET類庫，該子類包含webform/webpage/mvc，用于桌面開發(fā)的 WPF類庫、WinForm類庫，用于通信交互的WCF、asp.net web api、Web Service類庫等等
什么是基元類型？
像上文在CTS中提到了 基本基元數(shù)據(jù)類型，大家知道，每門語言都會定義一些基礎的類型，比如C#通過 int 來定義整型，用 string 來定義 字符串 ，用 object 來定義 根類。當我們來描述這樣一個類型的對象時可以有這兩種寫法，如圖：
我們可以看到，上邊用首字母小寫的藍色體string、object能描述，用首字母大寫的淺藍色String、Object也能描述,這兩種表述方式有何不同？
要知道，在vs默認的顏色方案中，藍色體 代表關(guān)鍵字，淺藍色體 代表類型。
那么這樣也就意味著，由微軟提供的FCL類庫里面 包含了 一些用于描述數(shù)據(jù)類型的 基礎類型，無論我們使用的是什么語言，只要引用了FCL，我們都可以通過new一個類的方式來表達數(shù)據(jù)類型。
如圖：
用new來創(chuàng)建這些類型的對象，但這樣就太繁瑣，所以C#就用 int關(guān)鍵字來表示System.Int32，用 string關(guān)鍵字來表示 System.String等，所以我們才能這樣去寫。
像這樣被表述于編譯器直接支持的類型叫做基元類型，它被直接映射于BCL中具體的類。
下面是部分面向.NET的語言的基元類型與對應的BCL的類別圖 ：
System.Object的意義
說起類型，這里要說CTS定義的一個非常重要的規(guī)則，就是類與類之間只能單繼承，System.Object類是所有類型的根，任何類都是顯式或隱式的繼承于System.Object。
System.Object定義了類型的最基本的行為：用于實例比較的Equals系列方法、用于Hash表中Hash碼的GetHashCode、用于Clr運行時獲取的類型信息GetType、用于表示當前對象字符串的ToString、用于執(zhí)行實例的淺復制MemberwiseClone、用于GC回收前操作的析構(gòu)方法Finalize 這6類方法。
所以 Object不僅是C#語言的類型根、還是VB等所有面向.NET的語言的類型根，它是整個FCL的類型根。
當然，CTS定義了單繼承，很多編程語言都滿足這個規(guī)則，但也有語言是例外，如C++就不做繼承限制，可以繼承多個，C++/CLI作為C++在對.NET的CLI實現(xiàn)，如果在非托管編碼中多繼承那也可以，如果試圖在托管代碼中多繼承，那就會報錯。我前面已經(jīng)舉過這樣特殊情況的例子，這也在另一方面反映出，各語言對CTS的支持并不是都如C#那樣全面的，我們只需明記一點：對于符合CTS的那部分自然就按照CTS定義的規(guī)則來。 任何可遵循CTS的類型規(guī)范，同時又有.NET運行時的實現(xiàn)的編程語言就可以成為.NET中的一員。
計算機是如何運行程序的？
接下來我要說什么是.NET的跨平臺，并解釋為什么能夠跨語言。不過要想知道什么是跨平臺，首先你得知道一個程序是如何在本機上運行的。
什么是CPU
CPU,全稱Central Processing Unit,叫做中央處理器,它是一塊超大規(guī)模的集成電路，是計算機組成上必不可少的組成硬件，沒了它，計算機就是個殼。
無論你編程水平怎樣，你都應該先知道，CPU是一臺計算機的運算核心和控制核心，CPU從存儲器或高速緩沖存儲器中取出指令，放入指令寄存器，并對指令譯碼，執(zhí)行指令。
我們運行一個程序，CPU就會不斷的讀取程序中的指令并執(zhí)行，直到關(guān)閉程序。事實上，從電腦開機開始，CPU就一直在不斷的執(zhí)行指令直到電腦關(guān)機。
什么是高級編程語言
在計算機角度，每一種CPU類型都有自己可以識別的一套指令集，計算機不管你這個程序是用什么語言來編寫的，其最終只認其CPU能夠識別的二進制指令集。
在早期計算機剛發(fā)展的時代，人們都是直接輸入01010101這樣的沒有語義的二進制指令來讓計算機工作的，可讀性幾乎沒有，沒人愿意直接編寫那些沒有可讀性、繁瑣、費時，易出差錯的二進制01代碼，所以后來才出現(xiàn)了編程語言。
編程語言的誕生，使得人們編寫的代碼有了可讀性，有了語義，與直接用01相比，更有利于記憶。
而前面說了，計算機最終只識別二進制的指令，那么，我們用編程語言編寫出來的代碼就必須要轉(zhuǎn)換成供機器識別的指令。
就像這樣：
code: 1+2 function 翻譯方法(參數(shù):code)
{
...
"1"=>"001";
"2"=>"002"; "+"=>"000";
return 能讓機器識別的二進制代碼;
}
call 翻譯方法("1+2")=> "001 000 002"
所以從一門編程語言所編寫的代碼文件轉(zhuǎn)換成能讓本機識別的指令，這中間是需要一個翻譯的過程。
而我們現(xiàn)在計算機上是運載著操作系統(tǒng)的，光翻譯成機器指令也不行，還得讓代碼文件轉(zhuǎn)化成可供操作系統(tǒng)執(zhí)行的程序才行。
那么這些步驟，就是編程語言所對應的編譯環(huán)節(jié)的工程了。這個翻譯過程是需要工具來完成，我們把它叫做 編譯器。
不同廠商的CPU有著不同的指令集，為了克服面向CPU的指令集的難讀、難編、難記和易出錯的缺點，后來就出現(xiàn)了面向特定CPU的特定匯編語言， 比如我打上這樣的x86匯編指令 mov ax,bx ，然后用上用機器碼做的匯編器，它將會被翻譯成 1000100111011000 這樣的二進制01格式的機器指令.
不同CPU架構(gòu)上的匯編語言指令不同，而為了統(tǒng)一一套寫法，同時又不失匯編的表達能力，C語言就誕生了。
用C語言寫的代碼文件，會被C編譯器先轉(zhuǎn)換成對應平臺的匯編指令，再轉(zhuǎn)成機器碼，最后將這些過程中產(chǎn)生的中間模塊鏈接成一個可以被操作系統(tǒng)執(zhí)行的程序。
那么匯編語言和C語言比較，我們就不需要去閱讀特定CPU的匯編碼，我只需要寫通用的C源碼就可以實現(xiàn)程序的編寫，我們用將更偏機器實現(xiàn)的匯編語言稱為低級語言，與匯編相比，C語言就稱之為高級語言。
在看看我們C#，我們在編碼的時候都不需要過于偏向特定平臺的實現(xiàn)，翻譯過程也基本遵循這個過程。它的編譯模型和C語言類似，都是屬于這種間接轉(zhuǎn)換的中間步驟，故而能夠跨平臺。
所以就類似于C/C#等這樣的高級語言來說是不區(qū)分平臺的，而在于其背后支持的這個 翻譯原理 是否能支持其它平臺。
什么是托管代碼，托管語言，托管模塊？
作為一門年輕的語言，C#借鑒了許多語言的長處，與C比較，C#則更為高級。
往往一段簡小的C#代碼，其功能卻相當于C的一大段代碼，并且用C#語言你幾乎不需要指針的使用，這也就意味著你幾乎不需要進行人為的內(nèi)存管控與安全考慮因素，也不需要多懂一些操作系統(tǒng)的知識，這讓編寫程序變得更加輕松和快捷。
如果說C#一段代碼可以完成其它低級語言一大段任務，那么我們可以說它特性豐富或者類庫豐富。而用C#編程不需要人為內(nèi)存管控是怎么做到的呢？
.NET提供了一個垃圾回收器(GC)來完成這部分工作，當你創(chuàng)建類型的時候，它會自動給你分配所需要的這部分內(nèi)存空間。就相當于，有一個專門的軟件或進程，它會讀取你的代碼，然后當你執(zhí)行這行代碼的時候，它幫你做了內(nèi)存分配工作。 這部分本該你做的工作，它幫你做了，這就是“托管”的概念。比如現(xiàn)實中 托管店鋪、托管教育等這樣的別人替你完成的概念。
因此，C#被稱之為托管語言。C#編寫的代碼也就稱之為托管代碼,C#生成的模塊稱之為托管模塊等。(對于托管的資源，是不需要也無法我們?nèi)斯とジ深A的，但我們可以了解它的一些機制原理，在后文我會簡單介紹。)
只要有比較，就會產(chǎn)生概念。那么在C#角度，那些脫離了.NET提供的諸如垃圾回收器這樣的環(huán)境管制，就是對應的 非托管了。
非托管的異常
我們編寫的程序有的模塊是由托管代碼編寫，有的模塊則調(diào)用了非托管代碼。在.NET Framework中也有一套基于此操作系統(tǒng)SEH的異常機制，理想的機制設定下我們可以直接通過catch(e)或catch來捕獲指定的異常和框架設計人員允許我們捕獲的異常。
而異常類型的級別也有大有小，有小到可以直接框架本身或用代碼處理的，有大到需要操作系統(tǒng)的異常機制來處理。.NET會對那些能讓程序崩潰的異常類型給進行標記，對于這部分異常，在.NET Framework 4.0之前允許開發(fā)人員在代碼中自己去處理，但4.0版本之后有所變更，這些被標記的異常默認不會在托管環(huán)境中拋出(即無法catch到)，而是由操作系統(tǒng)的SEH機制去處理。
不過如果你仍然想在代碼中捕獲處理這樣的異常也是可以的，你可以對需要捕獲的方法上標記[System.Runtime.ExceptionServices.HandleProcessCorruptedStateExceptionsAttribute]特性，就可以在該方法內(nèi)通過catch捕獲到該類型的異常。你也可以通過在配置文件中添加運行時節(jié)點來對全局進行這樣的一個配置：
HandleProcessCorruptedStateExceptions特性：https://msdn.microsoft.com/zh-cn/library/azure/system.runtime.exceptionservices.handleprocesscorruptedstateexceptionsattribute.aspx
SEHException類：https://msdn.microsoft.com/en-us/library/system.runtime.interopservices.sehexception(v=vs.100).aspx
處理損壞狀態(tài)異常博客專欄： https://msdn.microsoft.com/zh-cn/magazine/dd419661.aspx
什么是CLR，.NET虛擬機？
實際上，.NET不僅提供了自動內(nèi)存管理的支持，他還提供了一些列的如類型安全、應用程序域、異常機制等支持，這些 都被統(tǒng)稱為CLR公共語言運行庫。
CLR是.NET類型系統(tǒng)的基礎，所有的.NET技術(shù)都是建立在此之上，熟悉它可以幫助我們更好的理解框架組件的核心、原理。
在我們執(zhí)行托管代碼之前，總會先運行這些運行庫代碼，通過運行庫的代碼調(diào)用，從而構(gòu)成了一個用來支持托管程序的運行環(huán)境，進而完成諸如不需要開發(fā)人員手動管理內(nèi)存，一套代碼即可在各大平臺跑的這樣的操作。
這套環(huán)境及體系之完善，以至于就像一個小型的系統(tǒng)一樣，所以通常形象的稱CLR為".NET虛擬機"。那么，如果以進程為最低端，進程的上面就是.NET虛擬機(CLR)，而虛擬機的上面才是我們的托管代碼。換句話說，托管程序?qū)嶋H上是寄宿于.NET虛擬機中。
什么是CLR宿主進程，運行時主機？
那么相對應的，容納.NET虛擬機的進程就是CLR宿主進程了，該程序稱之為運行時主機。
這些運行庫的代碼，全是由C/C++編寫，具體表現(xiàn)為以mscoree.dll為代表的核心dll文件，該dll提供了N多函數(shù)用來構(gòu)建一個CLR環(huán)境 ，最后當運行時環(huán)境構(gòu)建完畢(一些函數(shù)執(zhí)行完畢)后，調(diào)用_CorDllMain或_CorExeMain來查找并執(zhí)行托管程序的入口方法(如控制臺就是Main方法)。
如果你足夠熟悉CLR，那么你完全可以在一個非托管程序中通過調(diào)用運行庫函數(shù)來定制CLR并執(zhí)行托管代碼。
像SqlServer就集成了CLR，可以使用任何 .NET Framework 語言編寫存儲過程、觸發(fā)器、用戶定義類型、用戶定義函數(shù)（標量函數(shù)和表值函數(shù)）以及用戶定義的聚合函數(shù)。
有關(guān)CLR大綱介紹： https://msdn.microsoft.com/zh-cn/library/9x0wh2z3(v=vs.85).aspx
CLR集成： https://docs.microsoft.com/zh-cn/previous-versions/sql/sql-server-2008/ms131052(v%3dsql.100)
構(gòu)造CLR的接口：https://msdn.microsoft.com/zh-cn/library/ms231039(v=vs.85).aspx
適用于 .NET Framework 2.0 的宿主接口：https://msdn.microsoft.com/zh-cn/library/ms164336(v=vs.85).aspx
選擇CLR版本： https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/file-schema/startup/supportedruntime-element
所以C#編寫的程序如果想運行就必須要依靠.NET提供的CLR環(huán)境來支持。 而CLR是.NET技術(shù)框架中的一部分，故只要在Windows系統(tǒng)中安裝.NET Framework即可。
Windows系統(tǒng)自帶.NET Framework
Windows系統(tǒng)默認安裝的有.NET Framework，并且可以安裝多個.NET Framework版本，你也不需要因此卸載，因為你使用的應用程序可能依賴于特定版本，如果你移除該版本，則應用程序可能會中斷。
Microsoft .NET Framework百度百科下有windows系統(tǒng)默認安裝的.NET版本
圖出自 https://baike.baidu.com/item/Microsoft%20.NET%20Framework/9926417?fr=aladdin
.NET Framework 4.0.30319
在%SystemRoot%\Microsoft.NET下的Framework和Framework64文件夾中分別可以看到32位和64位的.NET Framework安裝的版本。
我們點進去可以看到以.NET版本號為命名的文件夾，有2.0,3.0,3.5,4.0這幾個文件夾。
.NET Framework4.X覆蓋更新
要知道.NET Framework版本目前已經(jīng)迭代到4.7系列，電腦上明明安裝了比4.0更高版本的.NET Framework，然而從文件夾上來看，最高不過4.0，這是為何？
原來自.NET Framework 4以來的所有.NET Framework版本都是直接在v4.0.30319文件夾上覆蓋更新，并且無法安裝以前的4.x系列的老版本，所以v4.0.30319這個目錄中其實放的是你最后一次更新的NET Framework版本。
.NET Framework覆蓋更新：https://docs.microsoft.com/en-us/dotnet/framework/install/guide-for-developers
如何確認本機安裝了哪些.NET Framework和對應CLR的版本？
我們可以通過注冊表等其它方式來查看安裝的最新版本：https://docs.microsoft.com/zh-cn/dotnet/framework/migration-guide/how-to-determine-which-versions-are-installed 。
不過如果不想那么復雜的話，還有種最直接簡單的：
那就是進入該目錄文件夾，隨便找到幾個文件對其右鍵，然后點擊詳細信息即可查看到對應的文件版本，可以依據(jù)文件版本估摸出.NET Framework版本，比如csc.exe文件。
什么是程序集
上文我介紹了編譯器，即將源代碼文件給翻譯成一個計算機可識別的二進制程序。而在.NET Framework目錄文件夾中就附帶的有 用于C#語言的命令行形式的編譯器csc.exe 和 用于VB語言的命令行形式的編譯器vbc.exe。
我們通過編譯器可以將后綴為.cs(C#)和.vb(VB)類型的文件編譯成程序集。
程序集是一個抽象的概念，不同的編譯選項會產(chǎn)生不同形式的程序集。以文件個數(shù)來區(qū)分的話，那么就分 單文件程序集(即一個文件)和多文件程序集(多個文件)。
而不論是單文件程序集還是多文件程序集，其總有一個核心文件，就是表現(xiàn)為后綴為.dll或.exe格式的文件。它們都是標準的PE格式的文件，主要由4部分構(gòu)成：
多文件程序集的誕生場景有：比如我想為.exe綁定資源文件(如Icon圖標)，或者我想按照功能以增量的方式來按需編譯成.dll文件。 通常很少情況下才會將源代碼編譯成多文件程序集，并且在VS IDE中總是將源代碼給編譯成單文件的程序集(要么是.dll或.exe)，所以接下來我就以單文件程序集為例來講解。
用csc.exe進行編譯
現(xiàn)在，我將演示一段文本是如何被csc.exe編譯成一個可執(zhí)行的控制臺程序的。
我們新建個記事本，然后將下面代碼復制上去。
后關(guān)閉記事本，將之.txt的后綴改為.cs的后綴(后綴是用來標示這個文件是什么類型的文件，并不影響文件的內(nèi)容)。
上述代碼相當于Web中的http.sys偽實現(xiàn)，是建立了通信的socket服務端，并通過while循環(huán)來不斷的監(jiān)視獲取包的數(shù)據(jù)實現(xiàn)最基本的監(jiān)聽功能，最終我們將通過csc.exe將該文本文件編譯成一個控制臺程序。
我已經(jīng)在前面講過BCL，基礎類庫。在這部分代碼中，為了完成我想要的功能，我用到了微軟已經(jīng)幫我們實現(xiàn)好了的String數(shù)據(jù)類型系列類(.NET下的一些數(shù)據(jù)類型)、Environment類(提供有關(guān)當前環(huán)境和平臺的信息以及操作它們的方法)、Console類(用于控制臺輸入輸出等)、Socket系列類(對tcp協(xié)議抽象的接口)、File文件系列類(對文件目錄等操作系統(tǒng)資源的一些操作)、Encoding類(字符流的編碼)等
這些類，都屬于BCL中的一部分，它們存在但不限于mscorlib.dll、System.dll、System.core.dll、System.Data.dll等這些程序集中。
附：不要糾結(jié)BCL到底存在于哪些dll中，總之，它是個物理分散，邏輯上的類庫總稱。
mscorlib.dll和System.dll的區(qū)別：https://stackoverflow.com/questions/402582/mscorlib-dll-system-dll
因為我用了這些類，那么按照編程規(guī)則我必須在代碼中using這些類的命名空間，并通過csc.exe中的 /r:dll路徑 命令來為生成的程序集注冊元數(shù)據(jù)表(即以AssemblyRef為代表的程序集引用表)。
而這些代碼引用了4個命名空間，但實際上它們只被包含在mscorlib.dll和System.dll中，那么我只需要在編譯的時候注冊這兩個dll的信息就行了。
好，接下來我將通過cmd運行csc.exe編譯器，再輸入編譯命令： csc /out:D:\demo.exe D:\dic\demo.cs /r:D:\dic\System.dll
/r：是將引用dll中的類型數(shù)據(jù)注冊到程序集中的元數(shù)據(jù)表中 。
/out:是輸出文件的意思，如果沒有該命令則默認輸出{name}.exe。
使用csc.exe編譯生成： https://docs.microsoft.com/zh-cn/dotnet/csharp/language-reference/compiler-options/command-line-building-with-csc-exe
csc編譯命令行介紹：https://www.cnblogs.com/shuang121/archive/2012/12/24/2830874.html
總之，你除了要掌握基本的編譯指令外，當你打上這行命令并按回車后，必須滿足幾個條件，1.是.cs后綴的c#格式文件，2.是 代碼語法等檢測分析必須正確，3.是 使用的類庫必須有出處(引用的dll)，當然 因為我是編譯為控制臺程序，所以還必須得有個靜態(tài)Main方法入口，以上缺一不可。
可以看出，這段命令我是將 位于D:\dic\的demo.cs文件給編譯成 位于D:\名為demo.exe的控制臺文件，并且因為在代碼中使用到了System.dll，所以還需要通過/r注冊該元數(shù)據(jù)表。
這里得注意為什么沒有/r:mscorlib.dll,因為mscorlib.dll地位的特殊，所以csc總是對每個程序集進行mscorlib.dll的注冊(自包含引用該dll),因此我們可以不用/r:mscorlib.dll這個引用命令，但為了演示效果我還是決定通過/nostdlib命令來禁止csc默認導入mscorlib.dll文件。
所以，最終命令是這樣的： csc D:\dic\demo.cs /r:D:\dic\mscorlib.dll /r:D:\dic\System.dll /nostdlib
因為沒有指定輸出文件/out選項， 所以會默認輸出在與csc同一目錄下名為demo.exe的文件。事實上，在csc的命令中，如果你沒有指定路徑，那么就默認采用在csc.exe的所在目錄的相對路徑。
而我們可以看到，在該目錄下有許多程序集，其中就包含我們需要的System.dll和mscorlib.dll，所以我們完全可以直接/r:mscorlib.dll /r:System.dll
而類似于System.dll、System.Data.dll這樣使用非常頻繁的程序集，我們其實不用每次編譯的時候都去手動/r一下，對于需要重復勞動的編譯指令，我們可以將其放在后綴為.rsp的指令文件中，然后在編譯時直接調(diào)用文件即可執(zhí)行里面的命令 @ {name}.rsp。
csc.exe默認包含csc.rsp文件,我們可以用/noconfig來禁止默認包含，而csc.rsp里面已經(jīng)寫好了我們會經(jīng)常用到的指令。
所以，最終我可以這樣寫 csc D:\dic\demo.cs 直接生成控制臺應用程序。
.NET程序執(zhí)行原理
好的，現(xiàn)在我們已經(jīng)有了一個demo.exe的可執(zhí)行程序，它是如何被我們運行的？。
C#源碼被編譯成程序集，程序集內(nèi)主要是由一些元數(shù)據(jù)表和IL代碼構(gòu)成，我們雙擊執(zhí)行該exe，Windows加載器將該exe(PE格式文件)給映射到虛擬內(nèi)存中，程序集的相關(guān)信息都會被加載至內(nèi)存中，并查看PE文件的入口點(EntryPoint)并跳轉(zhuǎn)至指定的mscoree.dll中的_CorExeMain函數(shù)，該函數(shù)會執(zhí)行一系列相關(guān)dll來構(gòu)造CLR環(huán)境，當CLR預熱后調(diào)用該程序集的入口方法Main()，接下來由CLR來執(zhí)行托管代碼(IL代碼)。
JIT編譯
前面說了，計算機最終只識別二進制的機器碼，在CLR下有一個用來將IL代碼轉(zhuǎn)換成機器碼的引擎，稱為Just In Time Compiler，簡稱JIT，CLR總是先將IL代碼按需通過該引擎編譯成機器指令再讓CPU執(zhí)行，在這期間CLR會驗證代碼和元數(shù)據(jù)是否類型安全(在對象上只調(diào)用正確定義的操作、標識與聲稱的要求一致、對類型的引用嚴格符合所引用的類型)，被編譯過的代碼無需JIT再次編譯，而被編譯好的機器指令是被存在內(nèi)存當中，當程序關(guān)閉后再打開仍要重新JIT編譯。
AOT編譯
CLR的內(nèi)嵌編譯器是即時性的，這樣的一個很明顯的好處就是可以根據(jù)當時本機情況生成更有利于本機的優(yōu)化代碼，但同樣的，每次在對代碼編譯時都需要一個預熱的操作，它需要一個運行時環(huán)境來支持，這之間還是有消耗的。
而與即時編譯所對應的，就是提前編譯了，英文為Ahead of Time Compilation，簡稱AOT，也稱之為靜態(tài)編譯。
在.NET中，使用Ngen.exe或者開源的.NET Native可以提前將代碼編譯成本機指令。
Ngen是將IL代碼提前給全部編譯成本機代碼并安裝在本機的本機映像緩存中，故而可以減少程序因JIT預熱的時間，但同樣的也會有很多注意事項，比如因JIT的喪失而帶來的一些特性就沒有了，如類型驗證。Ngen僅是盡可能代碼提前編譯，程序的運行仍需要完整的CLR來支持。
.NET Native在將IL轉(zhuǎn)換為本機代碼的時候，會嘗試消除所有元數(shù)據(jù)將依靠反射和元數(shù)據(jù)的代碼替換為靜態(tài)本機代碼，并且將完整的CLR替換為主要包含垃圾回收器的重構(gòu)運行時mrt100_app.dll。
.NET Native: https://docs.microsoft.com/zh-cn/dotnet/framework/net-native/
Ngen.exe：https://docs.microsoft.com/zh-cn/dotnet/framework/tools/ngen-exe-native-image-generator
Ngen與.NET Native比較：https://www.zhihu.com/question/27997478/answer/38978762
---------------------------------------------------
現(xiàn)在，我們可以通過ILDASM工具(一款查看程序集IL代碼的軟件，在Microsoft SDKs目錄中的子目錄中)來查看該程序集的元數(shù)據(jù)表和Main方法中間碼。
c#源碼第一行代碼：string rootDirectory=Environment.CurrentDirectory;被翻譯成IL代碼： call string [mscorlib/*23000001*/]System.Environment/*01000004*/::get_CurrentDirectory() /* 0A000003 */
這句話意思是調(diào)用 System.Environment類的get_CurrentDirectory()方法(屬性會被編譯為一個私有字段+對應get/set方法)。
點擊視圖=>元信息=>顯示，即可查看該程序集的元數(shù)據(jù)。
我們可以看到System.Environment標記值為01000004，在TypeRef類型引用表中找到該項:
注意圖，TypeRefName下面有該類型中被引用的成員，其標記值為0A000003，也就是get_CurrentDirectory了。
而從其ResolutionScope指向位于0x23000001而得之，該類型存在于mscorlib程序集。
于是我們打開mscorlib.dll的元數(shù)據(jù)清單，可以在類型定義表(TypeDef)找到System.Environment,可以從元數(shù)據(jù)得知該類型的一些標志(Flags,常見的public、sealed、class、abstract)，也得知繼承(Extends)于System.Object。在該類型定義下還有類型的相關(guān)信息，我們可以在其中找到get_CurrentDirectory方法。 我們可以得到該方法的相關(guān)信息，這其中表明了該方法位于0x0002b784這個相對虛地址(RVA)，接著JIT在新地址處理CIL，周而復始。
元數(shù)據(jù)在運行時的作用： https://docs.microsoft.com/zh-cn/dotnet/standard/metadata-and-self-describing-components#run-time-use-of-metadata
程序集的規(guī)則
上文我通過ILDASM來描述CLR執(zhí)行代碼的方式，但還不夠具體，還需要補充的是對于程序集的搜索方式。
對于System.Environment類型，它存在于mscorlib.dll程序集中，demo.exe是個獨立的個體，它通過csc編譯的時候只是注冊了引用mscorlib.dll中的類型的引用信息，并沒有記錄mscorlib.dll在磁盤上的位置，那么，CLR怎么知道get_CurrentDirectory的代碼？它是從何處讀取mscorlib.dll的？
對于這個問題，.NET有個專門的概念定義，我們稱為 程序集的加載方式。
程序集的加載方式
對于自身程序集內(nèi)定義的類型，我們可以直接從自身程序集中的元數(shù)據(jù)中獲取，對于在其它程序集中定義的類型，CLR會通過一組規(guī)則來在磁盤中找到該程序集并加載在內(nèi)存。
CLR在查找引用的程序集的位置時候，第一個判斷條件是 判斷該程序集是否被簽名。
什么是簽名？
強名稱程序集
就比如大家都叫張三，姓名都一樣，喊一聲張三不知道到底在叫誰。這時候我們就必須擴展一下這個名字以讓它具有唯一性。
我們可以通過sn.exe或VS對項目右鍵屬性在簽名選項卡中采取RSA算法對程序集進行數(shù)字簽名（加密：公鑰加密，私鑰解密。簽名：私鑰簽名，公鑰驗證簽名），會將構(gòu)成程序集的所有文件通過哈希算法生成哈希值，然后通過非對稱加密算法用私鑰簽名，最后公布公鑰生成一串token，最終將生成一個由程序集名稱、版本號、語言文化、公鑰組成的唯一標識，它相當于一個強化的名稱，即強名稱程序集。
mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
我們?nèi)粘Ｔ赩S中的項目默認都沒有被簽名，所以就是弱名稱程序集。強名稱程序集是具有唯一標識性的程序集，并且可以通過對比哈希值來比較程序集是否被篡改，不過仍然有很多手段和軟件可以去掉程序集的簽名。
需要值得注意的一點是：當你試圖在已生成好的強名稱程序集中引用弱名稱程序集，那么你必須對弱名稱程序集進行簽名并在強名稱程序集中重新注冊。
之所以這樣是因為一個程序集是否被篡改還要考慮到該程序集所引用的那些程序集，根據(jù)CLR搜索程序集的規(guī)則(下文會介紹)，沒有被簽名的程序集可以被隨意替換，所以考慮到安全性，強名稱程序集必須引用強名稱程序集，否則就會報錯：需要強名稱程序集。
.NET Framework 4.5中對強簽名的更改：https://docs.microsoft.com/zh-cn/dotnet/framework/app-domains/enhanced-strong-naming
程序集搜索規(guī)則
事實上，按照存儲位置來說，程序集分為共享(全局)程序集和私有程序集。
CLR查找程序集的時候，會先判斷該程序集是否被強簽名，如果強簽名了那么就會去共享程序集的存儲位置(后文的GAC)去找，如果沒找到或者該程序集沒有被強簽名，那么就從該程序集的同一目錄下去尋找。
強名稱程序集是先找到與程序集名稱(VS中對項目右鍵屬性應用程序->程序集名稱)相等的文件名稱，然后 按照唯一標識再來確認，確認后CLR加載程序集，同時會通過公鑰效驗該簽名來驗證程序集是否被篡改(如果想跳過驗證可查閱https://docs.microsoft.com/zh-cn/dotnet/framework/app-domains/how-to-disable-the-strong-name-bypass-feature)，如果強名稱程序集被篡改則報錯。
而弱名稱程序集則直接按照與程序集名稱相等的文件名稱來找，如果還是沒有找到就以該程序集名稱為目錄的文件夾下去找。總之，如果最終結(jié)果就是沒找到那就會報System.IO.FileNotFoundException異常，即嘗試訪問磁盤上不存在的文件失敗時引發(fā)的異常。
注意：此處文件名稱和程序集名稱是兩個概念，不要模棱兩可，文件CLR頭內(nèi)嵌程序集名稱。
舉個例子：
我有一個控制臺程序，其路徑為D:\Demo\Debug\demo.exe，通過該程序的元數(shù)據(jù)得知，其引用了一個程序集名稱為aa的普通程序集，引用了一個名為bb的強名稱程序集，該bb.dll的強名稱標識為：xx001。
現(xiàn)在CLR開始搜索程序集aa，首先它會從demo.exe控制臺的同一目錄(也就是D:\Demo\Debug\)中查找程序集aa，搜索文件名為aa.dll的文件，如果沒找到就在該目錄下以程序集名稱為目錄的目錄中查找，也就是會查 D:\Demo\Debug\aa\aa.dll，這也找不到那就報錯。
然后CLR開始搜索程序集bb，CLR從demo.exe的元數(shù)據(jù)中發(fā)現(xiàn)bb是強名稱程序集，其標識為:xx001。于是CLR會先從一個被定義為GAC的目錄中去通過標識找，沒找到的話剩下的尋找步驟就和尋找aa一樣完全一致了。
當然，你也可以通過配置文件config中(配置文件存在于應用程序的同一目錄中)人為增加程序集搜索規(guī)則：
1.在運行時runtime節(jié)點中，添加privatePath屬性來添加搜索目錄，不過只能填寫相對路徑：
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="relative1;relative2;" /> //程序集當前目錄下的相對路徑目錄，用;號分割
</assemblyBinding>
</runtime>
2.如果程序集是強簽名后的，那么可以通過codeBase來指定網(wǎng)絡路徑或本地絕對路徑。
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="myAssembly"
publicKeyToken="32ab4ba45e0a69a1"
culture="neutral" />
<codeBase version="2.0.0.0"
/>
</dependentAssembly>
</assemblyBinding>
</runtime>
當然，我們還可以在代碼中通過AppDomain類中的幾個成員來改變搜索規(guī)則，如AssemblyResolve事件、AppDomainSetup類等。
有關(guān)運行時節(jié)點的描述:https://docs.microsoft.com/zh-cn/dotnet/framework/configure-apps/file-schema/runtime/runtime-element
項目的依賴順序
如果沒有通過config或者在代碼中來設定CLR搜索程序集的規(guī)則，那么CLR就按照默認的也就是我上述所說的模式來尋找。
所以如果我們通過csc.exe來編譯項目，引用了其它程序集的話，通常需要將那些程序集復制到同一目錄下。故而每當我們通過VS編譯器對項目右鍵重新生成項目(重新編譯)時，VS都會將引用的程序集給復制一份到項目bin\輸出目錄Debug文件夾下，我們可以通過VS中對引用的程序集右鍵屬性-復制本地 True/Flase 來決定這一默認行為。
值得一提的是，項目間的生成是有序生成的，它取決于項目間的依賴順序。
比如Web項目引用BLL項目，BLL項目引用了DAL項目。那么當我生成Web項目的時候，因為我要注冊Bll程序集，所以我要先生成Bll程序集，而BLL程序集又引用了Dal，所以又要先生成Dal程序集，所以程序集生成順序就是Dal=>BLL=>Web，項目越多編譯的時間就越久。
程序集之間的依賴順序決定了編譯順序，所以在設計項目間的分層劃分時不僅要體現(xiàn)出層級職責，還要考慮到依賴順序。代碼存放在哪個項目要有講究，不允許出現(xiàn)互相引用的情況，比如A項目中的代碼引用B，B項目中的代碼又引用A。
為什么Newtonsoft.Json版本不一致？
而除了注意編譯順序外，我們還要注意程序集間的版本問題，版本間的錯亂會導致程序的異常。
舉個經(jīng)典的例子：Newtonsoft.Json的版本警告，大多數(shù)人都知道通過版本重定向來解決這個問題，但很少有人會琢磨為什么會出現(xiàn)這個問題，找了一圈文章，沒找到一個解釋的。
比如：
A程序集引用了 C盤:\Newtonsoft.Json 6.0程序集
B程序集引用了 從Nuget下載下來的Newtonsoft.Json 10.0程序集
此時A引用B，就會報：發(fā)現(xiàn)同一依賴程序集的不同版本間存在無法解決的沖突 這一警告。
A：引用Newtonsoft.Json 6.0
Func()
{ var obj=Newtonsoft.Json.Obj;
B.Convert();
}
B: 引用Newtonsoft.Json 10.0
JsonObj()
{ return Newtonsoft.Json.Obj;
}
A程序集中的Func方法調(diào)用了B程序集中的JsonObj方法，JsonObj方法又調(diào)用了Newtonsoft.Json 10.0程序集中的對象，那么當執(zhí)行Func方法時程序就會異常，報System.IO.FileNotFoundException: 未能加載文件或程序集Newtonsoft.Json 10.0的錯誤。
這是為什么？
1.這是因為依賴順序引起的。A引用了B，首先會先生成B，而B引用了 Newtonsoft.Json 10.0，那么VS就會將源引用文件(Newtonsoft.Json 10.0)復制到B程序集同一目錄(bin/Debug)下，名為Newtonsoft.Json.dll文件，其內(nèi)嵌程序集版本為10.0。
2.然后A引用了B，所以會將B程序集和B程序集的依賴項(Newtonsoft.Json.dll)給復制到A的程序集目錄下，而A又引用了C盤的Newtonsoft.Json 6.0程序集文件，所以又將C:\Newtonsoft.Json.dll文件給復制到自己程序集目錄下。因為兩個Newtonsoft.Json.dll重名，所以直接覆蓋了前者，那么只保留了Newtonsoft.Json 6.0。
3.當我們調(diào)用Func方法中的B.Convert()時候，CLR會搜索B程序集，找到后再調(diào)用 return Newtonsoft.Json.Obj 這行代碼，而這行代碼又用到了Newtonsoft.Json程序集，接下來CLR搜索Newtonsoft.Json.dll，文件名稱滿足，接下來CLR判斷其標識，發(fā)現(xiàn)版本號是6.0，與B程序集清單里注冊的10.0版本不符，故而才會報出異常：未能加載文件或程序集Newtonsoft.Json 10.0。
以上就是為何Newtonsoft.Json版本不一致會導致錯誤的原因，其也詮釋了CLR搜索程序集的一個過程。
那么，如果我執(zhí)意如此，有什么好的解決方法能讓程序順利執(zhí)行呢？有，有2個方法。
第一種：通過bindingRedirect節(jié)點重定向，即當找到10.0的版本時，給定向到6.0版本
如何在編譯時加載兩個相同的程序集？
注意：我看過有的文章里寫的一個AppDomain只能加載一個相同的程序集，很多人都以為不能同時加載2個不同版本的程序集，實際上CLR是可以同時加載Newtonsoft.Json 6.0和Newtonsoft.Json 10.0的。
第二種：對每個版本指定codeBase路徑，然后分別放上不同版本的程序集，這樣就可以加載兩個相同的程序集。
如何同時調(diào)用兩個兩個相同命名空間和類型的程序集？
除了程序集版本不同外，還有一種情況就是，我一個項目同時引用了程序集A和程序集B，但程序集A和程序集B中的命名空間和類型名稱完全一模一樣，這個時候我調(diào)用任意一個類型都無法區(qū)分它是來自于哪個程序集的，那么這種情況我們可以使用extern alias外部別名。
我們需要在所有代碼前定義別名，extern alias a;extern alias b;，然后在VS中對引用的程序集右鍵屬性-別名，分別將其更改為a和b(或在csc中通過/r:{別名}={程序集}.dll)。
在代碼中通過 {別名}::{命名空間}.{類型}的方式來使用。
extern-alias介紹： https://docs.microsoft.com/zh-cn/dotnet/csharp/language-reference/keywords/extern-alias
共享程序集GAC
我上面說了這么多有關(guān)CLR加載程序集的細節(jié)和規(guī)則，事實上，類似于mscorlib.dll、System.dll這樣的FCL類庫被引用的如此頻繁，它已經(jīng)是我們.NET編程中必不可少的一部分，幾盡每個項目都會引用，為了不再每次使用的時候都復制一份，所以計算機上有一個位置專門存儲這些我們都會用到的程序集，叫做全局程序集緩存(Global Assembly Cache,GAC)，這個位置一般位于C:\Windows\Microsoft.NET\assembly和3.5之前版本的C:\Windows\assembly。
既然是共享存放的位置，那不可避免的會遇到文件名重復的情況，那么為了杜絕該類情況，規(guī)定在GAC中只能存在強名稱程序集，每當CLR要加載強名稱程序集時，會先通過標識去GAC中查找，而考慮到程序集文件名稱一致但版本文化等復雜的情況，所以GAC有自己的一套目錄結(jié)構(gòu)。我們?nèi)绻雽⒆约旱某绦蚣湃隚AC中，那么就必須先簽名，然后通過如gacutil.exe工具(其存在于命令行工具中 https://docs.microsoft.com/zh-cn/dotnet/framework/tools/developer-command-prompt-for-vs中)來注冊至GAC中，值得一提的是在將強名稱程序集安裝在GAC中，會效驗簽名。
GAC工具： https://docs.microsoft.com/en-us/dotnet/framework/tools/gacutil-exe-gac-tool
延伸
CLR是按需加載程序集的，沒有執(zhí)行代碼也就沒有調(diào)用相應的指令，沒有相應的指令，CLR也不會對其進行相應的操作。 當我們執(zhí)行Environment.CurrentDirectory這段代碼的時候，CLR首先要獲取Environment類型信息，通過自身元數(shù)據(jù)得知其存在mscorlib.dll程序集中，所以CLR要加載該程序集，而mscorlib.dll又由于其地位特殊，早在CLR初始化的時候就已經(jīng)被類型加載器自動加載至內(nèi)存中，所以這行代碼可以直接在內(nèi)存中讀取到類型的方法信息。
在這個章節(jié)，我雖然描述了CLR搜索程序集的規(guī)則，但事實上，加載程序集讀取類型信息遠遠沒有這么簡單，這涉及到了屬于.NET Framework獨有的"應用程序域"概念和內(nèi)存信息的查找。
簡單延伸兩個問題，mscorlib.dll被加載在哪里？內(nèi)存堆中又是什么樣的一個情況？
應用程序域
傳統(tǒng)非托管程序是直接承載在Windows進程中，托管程序是承載在.NET虛擬機CLR上的，而在CLR中管控的這部分資源中，被分成了一個個邏輯上的分區(qū)，這個邏輯分區(qū)被稱為應用程序域，是.NET Framework中定義的一個概念。
因為堆內(nèi)存的構(gòu)建和刪除都通過GC去托管，降低了人為出錯的幾率，在此特性基礎上.NET強調(diào)在一個進程中通過CLR強大的管理建立起對資源邏輯上的隔離區(qū)域，每個區(qū)域的應用程序互不影響，從而讓托管代碼程序的安全性和健壯性得到了提升。
熟悉程序集加載規(guī)則和AppDomain是在.NET技術(shù)下進行插件編程的前提。AppDomain這部分概念并不復雜。
當啟動一個托管程序時，最先啟動的是CLR，在這過程中會通過代碼初始化三個邏輯區(qū)域，最先是SystemDomain系統(tǒng)程序域，然后是SharedDoamin共享域，最后是{程序集名稱}Domain默認域。
系統(tǒng)程序域里維持著一些系統(tǒng)構(gòu)建項，我們可以通過這些項來監(jiān)控并管理其它應用程序域等。共享域存放著其它域都會訪問到的一些信息，當共享域初始化完畢后，會自動加載mscorlib.dll程序集至該共享域。而默認域則用儲存自身程序集的信息，我們的主程序集就會被加載至這個默認域中，執(zhí)行程序入口方法，在沒有特殊動作外所產(chǎn)生的一切耗費都發(fā)生在該域。
我們可以在代碼中創(chuàng)建和卸載應用程序域，域與域之間有隔離性，掛掉A域不會影響到B域，并且對于每一個加載的程序集都要指定域的，沒有在代碼中指定域的話，默認都是加載至默認域中。
AppDomain可以想象成組的概念，AppDomain包含了我們加載的一組程序集。我們通過代碼卸載AppDomain，即同時卸載了該AppDomain中所加載的所有程序集在內(nèi)存中的相關(guān)區(qū)域。
AppDomain的初衷是邊緣隔離，它可以讓程序不重新啟動而長時間運行，圍繞著該概念建立的體系從而讓我們能夠使用.NET技術(shù)進行插件編程。
當我們想讓程序在不關(guān)閉不重新部署的情況下添加一個新的功能或者改變某一塊功能，我們可以這樣做：將程序的主模塊仍默認加載至默認域，再創(chuàng)建一個新的應用程序域，然后將需要更改或替換的模塊的程序集加載至該域，每當更改和替換的時候直接卸載該域即可。 而因為域的隔離性，我在A域和B域加載同一個程序集，那么A域和B域就會各存在內(nèi)存地址不同但數(shù)據(jù)相同的程序集數(shù)據(jù)。
跨邊界訪問
事實上，在開發(fā)中我們還應該注意跨域訪問對象的操作(即在A域中的程序集代碼直接調(diào)用B域中的對象)是與平常編程中有所不同的，一個域中的應用程序不能直接訪問另一個域中的代碼和數(shù)據(jù)，對于這樣的在進程內(nèi)跨域訪問操作分兩類。
一是按引用封送，需要繼承System.MarshalByRefObject，傳遞的是該對象的代理引用，與源域有相同的生命周期。
二是按值封送，需要被[Serializable]標記，是通過序列化傳遞的副本，副本與源域的對象無關(guān)。
無論哪種方式都涉及到兩個域直接的封送、解封，所以跨域訪問調(diào)用不適用于過高頻率。
(比如，原來你是這樣調(diào)用對象： var user=new User(); 現(xiàn)在你要這樣：var user=(User){應用程序域?qū)ο髮嵗齷.CreateInstanceFromAndUnwrap("Model.dll","Model.User"); )
值得注意的是，應用程序域是對程序集的組的劃分，它與進程中的線程是兩個一橫一豎，方向不一樣的概念，不應該將這2個概念放在一起比較。我們可以通過Thread.GetDomain來查看執(zhí)行線程所在的域。
應用程序域在類庫中是System.AppDomain類,部分重要的成員有：
獲取當前 System.Threading.Thread 的當前應用程序域 public static AppDomain CurrentDomain { get; }
使用指定的名稱新建應用程序域 public static AppDomain CreateDomain(string friendlyName);
卸載指定的應用程序域。 public static void Unload(AppDomain domain);
指示是否對當前進程啟用應用程序域的 CPU 和內(nèi)存監(jiān)視，開啟后可以根據(jù)相關(guān)屬性進行監(jiān)控 public static bool MonitoringIsEnabled { get; set; }
當前域托管代碼拋出異常時最先發(fā)生的一個事件，框架設計中可以用到 public event EventHandler<FirstChanceExceptionEventArgs> FirstChanceException;
當某個異常未被捕獲時調(diào)用該事件，如代碼里只catch了a異常，實際產(chǎn)生的是 b異常，那么b異常就沒有捕捉到。 public event UnhandledExceptionEventHandler UnhandledException;
為指定的應用程序域?qū)傩苑峙渲付ㄖ怠Ｔ搼贸绦蛴虻木植看鎯χ担摯鎯Σ粍澐稚舷挛暮途€程，均可通過GetData獲取。 public void SetData(string name, object data);
如果想使用托管代碼來覆蓋CLR的默認行為https://msdn.microsoft.com/zh-cn/library/system.appdomainmanager(v=vs.85).aspx
public AppDomainManager DomainManager { get; }
返回域的配置信息，如在config中配置的節(jié)點信息 public AppDomainSetup SetupInformation { get; }
應用程序域： https://docs.microsoft.com/zh-cn/dotnet/framework/app-domains/application-domains
AppDomain和AppPool
注意：此處的AppDomain應用程序域 和 IIS中的AppPool應用程序池 是2個概念，AppPool是IIS獨有的概念，它也相當于一個組的概念，對網(wǎng)站進行劃組，然后對組進行一些如進程模型、CPU、內(nèi)存、請求隊列的高級配置。
內(nèi)存
應用程序域把資源給隔離開，這個資源，主要指內(nèi)存。那么什么是內(nèi)存呢？
要知道，程序運行的過程就是電腦不斷通過CPU進行計算的過程，這個過程需要讀取并產(chǎn)生運算的數(shù)據(jù)，為此我們需要一個擁有足夠容量能夠快速與CPU交互的存儲容器，這就是內(nèi)存了。對于內(nèi)存大小，32位處理器，尋址空間最大為2的32次方byte，也就是4G內(nèi)存，除去操作系統(tǒng)所占用的公有部分，進程大概能占用2G內(nèi)存，而如果是64位處理器，則是8T。
而在.NET中，內(nèi)存區(qū)域分為堆棧和托管堆。
堆棧和堆的區(qū)別
堆和堆棧就內(nèi)存而言只不過是地址范圍的區(qū)別。不過堆棧的數(shù)據(jù)結(jié)構(gòu)和其存儲定義讓其在時間和空間上都緊密的存儲，這樣能帶來更高的內(nèi)存密度，能在CPU緩存和分頁系統(tǒng)表現(xiàn)的更好。故而訪問堆棧的速度總體來說比訪問堆要快點。
線程堆棧
操作系統(tǒng)會為每條線程分配一定的空間，Windwos為1M，這稱之為線程堆棧。在CLR中的棧主要用來執(zhí)行線程方法時，保存臨時的局部變量和函數(shù)所需的參數(shù)及返回的值等，在棧上的成員不受GC管理器的控制，它們由操作系統(tǒng)負責分配，當線程走出方法后，該棧上成員采用后進先出的順序由操作系統(tǒng)負責釋放，執(zhí)行效率高。
而托管堆則沒有固定容量限制，它取決于操作系統(tǒng)允許進程分配的內(nèi)存大小和程序本身對內(nèi)存的使用情況，托管堆主要用來存放對象實例，不需要我們?nèi)斯とシ峙浜歪尫牛溆蒅C管理器托管。
為什么值類型存儲在棧上
不同的類型擁有不同的編譯時規(guī)則和運行時內(nèi)存分配行為，我們應知道，C# 是一種強類型語言，每個變量和常量都有一個類型，在.NET中，每種類型又被定義為值類型或引用類型。
使用 struct、enum 關(guān)鍵字直接派生于System.ValueType定義的類型是值類型，使用 class、interface、delagate 關(guān)鍵字派生于System.Object定義的類型是引用類型。
對于在一個方法中產(chǎn)生的值類型成員，將其值分配在棧中。這樣做的原因是因為值類型的值其占用固定內(nèi)存的大小。
C#中int關(guān)鍵字對應BCL中的Int32，short對應Int16。Int32為2的32位，如果把32個二進制數(shù)排列開來，我們要求既能表達正數(shù)也能表達負數(shù)，所以得需要其中1位來表達正負，首位是0則為+，首位是1則為-，那么我們能表示數(shù)據(jù)的數(shù)就只有31位了，而0是介于-1和1之間的整數(shù)，所以對應的Int32能表現(xiàn)的就是2的31次方到2的31次方-1，即2147483647和-2147483648這個整數(shù)段。
1個字節(jié)=8位，32位就是4個字節(jié)，像這種以Int32為代表的值類型，本身就是固定的內(nèi)存占用大小，所以將值類型放在內(nèi)存連續(xù)分配的棧中。
托管堆模型
而引用類型相比值類型就有點特殊，newobj創(chuàng)建一個引用類型，因其類型內(nèi)的引用對象可以指向任何類型，故而無法準確得知其固定大小，所以像對于引用類型這種無法預知的容易產(chǎn)生內(nèi)存碎片的動態(tài)內(nèi)存，我們把它放到托管堆中存儲。
托管堆由GC托管，其分配的核心在于堆中維護著一個nextObjPtr指針，我們每次實例(new)一個對象的時候，CLR將對象存入堆中，并在棧中存放該對象的起始地址，然后該指針都會根據(jù)該對象的大小來計算下一個對象的起始地址。不同于值類型直接在棧中存放值，引用類型則還需要在棧中存放一個代表(指向)堆中對象的值(地址)。
而托管堆又可以因存儲規(guī)則的不同將其分類，托管堆可以被分為3類：
加載程序集就是將程序集中的信息給映射在加載堆，對產(chǎn)生的實例對象存放至垃圾回收堆。前文說過應用程序域是指通過CLR管理而建立起的邏輯上的內(nèi)存邊界，那么每個域都有其自己的加載堆，只有卸載應用程序域的時候，才會回收該域?qū)募虞d堆。
而加載堆中的高頻堆包含的有一個非常重要的數(shù)據(jù)結(jié)構(gòu)表---方法表，每個類型都僅有一份方法表(MethodTables)，它是對象的第一個實例創(chuàng)建前的類加載活動的結(jié)果，它主要包含了我們所關(guān)注的3部分信息：
那么，實例一個對象，CLR是如何將該對象所對應的類型行為及信息的內(nèi)存位置(加載堆)關(guān)聯(lián)起來的呢？
原來，在托管堆上的每個對象都有2個額外的供于CLR使用的成員，我們是訪問不到的，其中一個就是類型對象指針，它指向位于加載堆中的方法表從而讓類型的狀態(tài)和行為關(guān)聯(lián)了起來， 類型指針的這部分概念我們可以想象成obj.GetType()方法獲得的運行時對象類型的實例。而另一個成員就是同步塊索引，其主要用于2點：1.關(guān)聯(lián)內(nèi)置SyncBlock數(shù)組的項從而完成互斥鎖等目的。 2.是對象Hash值計算的輸入?yún)?shù)之一。
上述gif是我簡單畫的一個圖，可以看到對于方法中申明的值類型變量，其在棧中作為一塊值表示，我們可以直接通過c#運算符sizeof來獲得值類型所占byte大小。而方法中申明的引用類型變量，其在托管堆中存放著對象實例(對象實例至少會包含上述兩個固定成員以及實例數(shù)據(jù)，可能)，在棧中存放著指向該實例的地址。
當我new一個引用對象的時候，會先分配同步塊索引(也叫對象頭字節(jié))，然后是類型指針，最后是類型實例數(shù)據(jù)(靜態(tài)字段的指針存在于方法表中)。會先分配對象的字段成員，然后分配對象父類的字段成員，接著再執(zhí)行父類的構(gòu)造函數(shù)，最后才是本對象的構(gòu)造函數(shù)。這個多態(tài)的過程，對于CLR來說就是一系列指令的集合，所以不能糾結(jié)new一個子類對象是否會也會new一個父類對象這樣的問題。而也正是因為引用類型的這樣一個特征，我們雖然可以估計一個實例大概占用多少內(nèi)存，但對于具體占用的大小，我們需要專門的工具來測量。
對于引用類型，u2=u1，我們在賦值的時候，實際上賦的是地址，那么我改動數(shù)據(jù)實際上是改動該地址指向的數(shù)據(jù)，這樣一來，因為u2和u1都指向同一塊區(qū)域，所以我對u1的改動會影響到u2，對u2的改動會影響到u1。如果我想互不影響，那么我可以繼承IClone接口來實現(xiàn)內(nèi)存克隆，已有的CLR實現(xiàn)是淺克隆方法，但也只能克隆值類型和String(string是個特殊的引用類型，對于string的更改，其會產(chǎn)生一個新實例對象)，如果對包含其它引用類型的這部分，我們可以自己通過其它手段實現(xiàn)深克隆，如序列化、反射等方式來完成。而如果引用類型中包含有值類型字段，那么該字段仍然分配在堆上。
對于值類型，a=b，我們在賦值的時候，實際上是新建了個值，那么我改動a的值那就只會改動a的值，改動b的值就只會改動b的值。而如果值類型(如struct)中包含的有引用類型，那么仍是同樣的規(guī)則，引用類型的那部分實例在托管堆中，地址在棧上。
我如果將值類型放到引用類型中(如：object a=3)，會在棧中生成一個地址，在堆中生成該值類型的值對象，還會再生成這類型指針和同步塊索引兩個字段，這也就是常說裝箱，反過來就是拆箱。每一次的這樣的操作，都會涉及到內(nèi)存的分布、拷貝，可見，裝箱和拆箱是有性能損耗，因此應該減少值類型和引用類型之間轉(zhuǎn)換的次數(shù)。
但對于引用類型間的子類父類的轉(zhuǎn)換，僅是指令的執(zhí)行消耗，幾盡沒有開銷。
選class還是struct
那么我到底是該new一個class呢還是選擇struct呢？
通過上文知道對于class，用完之后對象仍然存在托管堆，占用內(nèi)存。對于struct，用完之后直接由操作系統(tǒng)銷毀。那么在實際開發(fā)中定義類型時，選擇class還是struct就需要注意了，要綜合應用場景來辨別。struct存在于棧上，棧和托管堆比較，最大的優(yōu)勢就是即用即毀。所以如果我們單純的傳遞一個類型，那么選擇struct比較合適。但須注意線程堆棧有容量限制，不可多存放超大量的值類型對象，并且因為是值類型直接傳遞副本，所以struct作為方法參數(shù)是線程安全的，但同樣要避免裝箱的操作。而相比較class，如果類型中還需要多一些封裝繼承多態(tài)的行為，那么class當然是更好的選擇。
GC管理器
值得注意的是，當我new完一個對象不再使用的時候，這個對象在堆中所占用的內(nèi)存如何處理？
在非托管世界中，可以通過代碼手動進行釋放，但在.NET中，堆完全由CLR托管，也就是說GC堆是如何具體來釋放的呢？
當GC堆需要進行清理的時候，GC收集器就會通過一定的算法來清理堆中的對象，并且版本不同算法也不同。最主要的則為Mark-Compact標記-壓縮算法。
這個算法的大概含義就是，通過一個圖的數(shù)據(jù)結(jié)構(gòu)來收集對象的根，這個根就是引用地址，可以理解為指向托管堆的這根關(guān)系線。當觸發(fā)這個算法時，會檢查圖中的每個根是否可達，如果可達就對其標記，然后在堆上找到剩余沒有標記(也就是不可達)的對象進行刪除，這樣，那些不在使用的堆中對象就刪除了。
前面說了，因為nextObjPtr的緣故，在堆中分配的對象都是連續(xù)分配的，因為未被標記而被刪除，那么經(jīng)過刪除后的堆就會顯得支零破碎，那么為了避免空間碎片化，所以需要一個操作來讓堆中的對象再變得緊湊、連續(xù)，而這樣一個操作就叫做：Compact壓縮。
而對堆中的分散的對象進行挪動后，還會修改這些被挪動對象的指向地址，從而得以正確的訪問，最后重新更新一下nextObjPtr指針，周而復始。
而為了優(yōu)化內(nèi)存結(jié)構(gòu)，減少在圖中搜索的成本，GC機制又為每個托管堆對象定義了一個屬性，將每個對象分成了3個等級，這個屬性就叫做：代，0代、1代、2代。
每當new一個對象的時候，該對象都會被定義為第0代，當GC開始回收的時候，先從0代回收，在這一次回收動作之后，0代中沒有被回收的對象則會被定義成第1代。當回收第1代的時候，第1代中沒有被清理掉的對象就會被定義到第2代。
CLR初始化時會為0/1/2這三代選擇一個預算的容量。0代通常以256 KB-4 MB之間的預算開始，1代的典型起始預算為512 KB-4 MB，2代不受限制，最大可擴展至操作系統(tǒng)進程的整個內(nèi)存空間。
比如第0代為256K，第1代為2MB。我們不停的new對象，直到這些對象達到256k的時候，GC會進行一次垃圾回收，假設這次回收中回收了156k的不可達對象，剩余100k的對象沒有被回收，那么這100k的對象就被定義為第1代。現(xiàn)在就變成了第0代里面什么都沒有，第1代里放的有100k的對象。這樣周而復始，GC清除的永遠都只有第0代對象，除非當?shù)谝淮械膶ο罄鄯e達到了定義的2MB的時候，才會連同清理第1代，然后第1代中活著的部分再升級成第二代...
第二代的容量是沒有限制，但是它有動態(tài)的閾值(因為等到整個內(nèi)存空間已滿以執(zhí)行垃圾回收是沒有意義的)，當達到第二代的閾值后會觸發(fā)一次0/1/2代完整的垃圾收集。
也就是說，代數(shù)越長說明這個對象經(jīng)歷了回收的次數(shù)也就越多，那么也就意味著該對象是不容易被清除的。
這種分代的思想來將對象分割成新老對象，進而配對不同的清除條件，這種巧妙的思想避免了直接清理整個堆的尷尬。
弱引用、弱事件
GC收集器會在第0代飽和時開始回收托管堆對象，對于那些已經(jīng)申明或綁定的不經(jīng)訪問的對象或事件，因為不經(jīng)常訪問而且還占內(nèi)存(有點懶加載的意思)，所以即時對象可達，但我想在GC回收的時候仍然對其回收，當需要用到的時候再創(chuàng)建，這種情況該怎么辦？
那么這其中就引入了兩個概念：
WeakReference弱引用、WeakEventManager弱事件
對于這2兩個不區(qū)分語言的共同概念，大家可自行擴展百度，此處就不再舉例。
GC堆回收
那么除了通過new對象而達到代的閾(臨界)值時，還有什么能夠?qū)е吕堰M行垃圾回收呢？ 還可能windows報告內(nèi)存不足、CLR卸載AppDomain、CLR關(guān)閉等其它特殊情況。
或者，我們還可以自己通過代碼調(diào)用。
.NET有GC來幫助開發(fā)人員管理內(nèi)存，并且版本也在不斷迭代。GC幫我們托管內(nèi)存，但仍然提供了System.GC類讓開發(fā)人員能夠輕微的協(xié)助管理。 這其中有一個可以清理內(nèi)存的方法(并沒有提供清理某個對象的方法)：GC.Collect方法，可以對所有或指定代進行即時垃圾回收(如果想調(diào)試，需在release模式下才有效果)。這個方法盡量別用，因為它會擾亂代與代間的秩序，從而讓低代的垃圾對象跑到生命周期長的高代中。
GC還提供了，判斷當前對象所處代數(shù)、判斷指定代數(shù)經(jīng)歷了多少次垃圾回收、獲取已在托管堆中分配的字節(jié)數(shù)這樣的三個方法，我們可以從這3個方法簡單的了解托管堆的情況。
托管世界的內(nèi)存不需要我們打理，我們無法從代碼中得知具體的托管對象的大小，你如果想追求對內(nèi)存最細微的控制，顯然C#并不適合你，不過類似于有關(guān)內(nèi)存把控的這部分功能模塊，我們可以通過非托管語言來編寫，然后通過.NET平臺的P/Invoke或COM技術(shù)(微軟為CLR定義了COM接口并在注冊表中注冊)來調(diào)用。
像FCL中的源碼，很多涉及到操作系統(tǒng)的諸如 文件句柄、網(wǎng)絡連接等外部extren的底層方法都是非托管語言編寫的，對于這些非托管模塊所占用的資源，我們可以通過隱式調(diào)用析構(gòu)函數(shù)(Finalize)或者顯式調(diào)用的Dispose方法通過在方法內(nèi)部寫上非托管提供的釋放方法來進行釋放。
像文中示例的socket就將釋放資源的方法寫入Dispose中，析構(gòu)函數(shù)和Close方法均調(diào)用Dispose方法以此完成釋放。事實上，在FCL中的使用了非托管資源的類大多都遵循IDispose模式。而如果你沒有釋放非托管資源直接退出程序，那么操作系統(tǒng)會幫你釋放該程序所占的內(nèi)存的。
垃圾回收對性能的影響
還有一點，垃圾回收是對性能有影響的。
GC雖然有很多優(yōu)化策略，但總之，只要當它開始回收垃圾的時候，為了防止線程在CLR檢查期間對對象更改狀態(tài)，所以CLR會暫停進程中的幾乎所有線程(所以線程太多也會影響GC時間)，而暫停的時間就是應用程序卡死的時間，為此，對于具體的處理細節(jié)，GC提供了2種配置模式讓我們選擇。
第一種為：單CPU的工作站模式，專為單CPU處理器定做。這種模式會采用一系列策略來盡可能減少GC回收中的暫停時間。
而工作站模式又分為并發(fā)(或后臺)與不并發(fā)兩種，并發(fā)模式表現(xiàn)為響應時間快速，不并發(fā)模式表現(xiàn)為高吞吐量。
第二種為：多CPU的服務器模式，它會為每個CPU都運行一個GC回收線程，通過并行算法來使線程能真正同時工作，從而獲得性能的提升。
我們可以通過在Config文件中更改配置來修改GC模式，如果沒有進行配置，那么應用程序總是默認為單CPU的工作站的并發(fā)模式，并且如果機器為單CPU的話，那么配置服務器模式則無效。
如果在工作站模式中想禁用并發(fā)模式，則應該在config中運行時節(jié)點添加 <gcConcurrent enabled="false" />
如果想更改至服務器模式，則可以添加 <gcServer enabled="true" />。
<configuration>
<runtime>
<!--<gcConcurrent enabled="true|false"/>-->
<!--<gcServer enabled="true|false"/>-->
</runtime>
</configuration>
gcConcurrent: https://docs.microsoft.com/zh-cn/dotnet/framework/configure-apps/file-schema/runtime/gcconcurrent-element
gcServer: https://docs.microsoft.com/zh-cn/dotnet/framework/configure-apps/file-schema/runtime/gcserver-element
性能建議
雖然我們可以選擇適合的GC工作模式來改善垃圾回收時的表現(xiàn)，但在實際開發(fā)中我們更應該注意減少不必要的內(nèi)存開銷。
幾個建議是，減換需要創(chuàng)建大量的臨時變量的模式、考慮對象池、大對象使用懶加載、對固定容量的集合指定長度、注意字符串操作、注意高頻率的隱式裝箱操作、延遲查詢、對于不需要面向?qū)ο筇匦缘念愑胹tatic、需要高性能操作的算法改用外部組件實現(xiàn)(p/invoke、com)、減少throw次數(shù)、注意匿名函數(shù)捕獲的外部對象將延長生命周期、可以閱讀GC相關(guān)運行時配置在高并發(fā)場景注意變換GC模式...
對于.NET中改善性能可延伸閱讀 https://msdn.microsoft.com/zh-cn/library/ms973838.aspx 、 https://msdn.microsoft.com/library/ms973839.aspx
.NET程序執(zhí)行圖
至此，.NET Framework上的三個重要概念，程序集、應用程序域、內(nèi)存在本文講的差不多了，我畫了一張圖簡單的概述.NET程序的一個執(zhí)行流程：
對于后文，我將單獨的介紹一些其它雜項，首先是.NET平臺的安全性。
.NET的安全性
.NET Framework中的安全機制分為 基于角色的安全機制 和 代碼訪問安全機制 。
基于角色的安全性
基于角色的安全機制作為傳統(tǒng)的訪問控制，其運用的非常廣泛，如操作系統(tǒng)的安全策略、數(shù)據(jù)庫的安全策略等等...它的概念就相當于我們經(jīng)常做的那些RBAC權(quán)限管理系統(tǒng)一樣，用戶關(guān)聯(lián)角色，角色關(guān)聯(lián)權(quán)限，權(quán)限對應著操作。
整個機制的安全邏輯就和我們平時編寫代碼判斷是一樣的，大致可以分為兩個步驟.
第一步就是創(chuàng)建一個主體，然后標識這個主體是什么身份(角色) ，第二步就是 身份驗證，也就是if判斷該身份是否可以這樣操作。
而在.NET Framework中，這主體可以是Windows賬戶，也可以是自定義的標識，通過生成如當前線程或應用程序域使用的主體相關(guān)的信息來支持授權(quán)。
比如，構(gòu)造一個代表當前登錄賬戶的主體對象WindowsPrincipal，然后通過 AppDomain.CurrentDomain.SetThreadPrincipal(主體對象);或Thread.CurrentPrincipal的set方法來設置應用程序域或線程的主體對象， 最后使用System.Security.Permissions.PrincipalPermission特性來標記在方法上來進行授權(quán)驗證。
如圖，我當前登錄賬號名稱為DemoXiaoZeng，然后通過Thread.CurrentPrincipal設置當前主體，執(zhí)行aa方法，順利打印111。如果檢測到PrincipalPermission類中的Name屬性值不是當前登錄賬號，那么就報錯：對主體權(quán)限請求失敗。
在官方文檔中有對.NET Framework基于角色的安全性的詳細的介紹，感興趣可以去了解 https://docs.microsoft.com/zh-cn/dotnet/standard/security/principal-and-identity-objects#principal-objects
代碼訪問安全性
在.NET Framework中還有一個安全策略，叫做 代碼訪問安全Code Access Security，也就是CAS了。
代碼訪問安全性在.NET Framework中是用來幫助限制代碼對受保護資源和操作的訪問權(quán)限。
舉個例子，我通過創(chuàng)建一個FileIOPermission對象來限制對后續(xù)代碼對D盤的文件和目錄的訪問，如果后續(xù)代碼對D盤進行資源操作則報錯。
FileIOPermission是代碼控制訪問文件和文件夾的能力。除了FileIOPermission外，還有如PrintingPermission代碼控制訪問打印機的權(quán)限、RegistryPermission代碼控制操作注冊表的權(quán)限、SocketPermission控制接受連接或啟動Socket連接的權(quán)限。
對于這些通過代碼來對受保護資源和操作的權(quán)限限制，也就是這些類名后綴為Permission的類，它們叫做 Permissions(權(quán)限)，都繼承自CodeAccessPermission，都有如Demand，Assert，Deny，PermitOnly，IsSubsetOf，Intersect和Union這些方法，在MSDN上有完整的權(quán)限列表：https://msdn.microsoft.com/en-us/library/h846e9b3(v=vs.100).aspx
為了確定代碼是否有權(quán)訪問某一資源或執(zhí)行某一操作，CLR的安全系統(tǒng)將審核調(diào)用堆棧，以將每個調(diào)用方獲得的權(quán)限與要求的權(quán)限進行比較。 如果調(diào)用堆棧中的任何調(diào)用方不具備要求的權(quán)限，則會引發(fā)安全性異常并拒絕訪問。
出自 https://docs.microsoft.com/zh-cn/dotnet/framework/misc/code-access-security
而除了Permissions權(quán)限，代碼訪問安全性機制還有 權(quán)限集、證據(jù)、代碼組、策略等概念。這些概念讓CAS如此強大，但相應的，它們也讓CAS變得復雜，必須為每個特定機器定義正確的PermissionSet和Code Groups才能設置成一個成功的CAS策略。
考慮到這層原因，Microsoft .NET安全小組決定從頭開始重建代碼訪問安全性。在.NET Framework4.0之后，就不再使用之前的那套CAS模型了，而是使用.NET Framework 2.0中引入的安全透明模型，然后稍加修改，修改后的安全透明模型成為保護資源的標準方法，被稱之為：安全透明度級別2
安全透明度2介紹：https://msdn.microsoft.com/en-us/library/dd233102(v=vs.100).aspx
.NET Framework4.0的安全更改：https://msdn.microsoft.com/en-us/library/dd233103(v=vs.100).aspx
一個完整的CAS演示：https://www.codeproject.com/Articles/5724/Understanding-NET-Code-Access-Security
對于安全透明度級別2我將不再介紹，感興趣的可以看我推薦的這2篇文章，對Level2的安全透明度介紹的比較詳細，包括實踐、遷移。
https://www.red-gate.com/simple-talk/dotnet/.net-framework/whats-new-in-code-access-security-in-.net-framework-4.0---part-i/
https://www.red-gate.com/simple-talk/dotnet/net-framework/whats-new-in-code-access-security-in-net-framework-4-0-part-2/
----------------------------------------------
須注意：
.NET平臺上的安全機制，僅僅是.NET平臺上的，因此它只限制于托管代碼，我們可以直接調(diào)用非托管代碼或進程通信間接調(diào)用非托管代碼等多個手段來突破對托管代碼 操作資源的限制。
事實上，我們在平常項目中代碼編寫的安全機制(業(yè)務邏輯身份驗證、項目框架驗證)與這些平臺級的安全機制沒什么不同。我們可以理解為代碼寫的位置不一樣，.NET安全機制是寫在CLR組件中，而我們的安全機制是寫在上層的代碼中。這些平臺級的標識更多的是和操作系統(tǒng)用戶有關(guān)，而我們項目代碼中的標識則是和在數(shù)據(jù)庫中注冊的用戶有關(guān)， 大家都是通過if else來去判斷，判斷的主體和格局不一樣，邏輯本質(zhì)都是相同的。
NET Core不支持代碼訪問安全性和安全性透明性。
.NET是什么
我在前文對.NET系統(tǒng)概述時，有的直接稱.NET，有的稱.NET Framework。那么準確來說什么是.NET?什么又是.NET Framework呢？
.NET是一個微軟搭造的開發(fā)者平臺，它主要包括：
.NET Framework是什么
事實上，像我上面講的那些諸如程序集、GC、AppDomain這樣的為CLR的一些概念組成，實質(zhì)上指的是.NET Framework CLR。
.NET平臺是微軟為了占據(jù)開發(fā)市場而成立的，不是無利益驅(qū)動的純技術(shù)平臺的那種東西。基于該平臺下的技術(shù)框架也因為 商業(yè)間的利益 從而和微軟自身的Windows操作系統(tǒng)所綁定。所以雖然平臺雄心和口號很大，但很多框架類庫技術(shù)都是以Windows系統(tǒng)為藍本，這樣就導致，雖然.NET各方面都挺好，但是用.NET就必須用微軟的東西，直接形成了技術(shù)-商業(yè)的綁定。
.NET Framework就是.NET 技術(shù)框架組成在Windows系統(tǒng)下的具體的實現(xiàn)，和Windows系統(tǒng)高度耦合，上文介紹的.NET系統(tǒng)，就是指.NET Framework。
部署.net Framework ：https://docs.microsoft.com/zh-cn/dotnet/framework/deployment/deployment-guide-for-developers
.NET Framework高級開發(fā)：https://docs.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2008/29eafad8(v%3dvs.90)
.NET Framework源碼在線瀏覽：https://referencesource.microsoft.com/
如何在VS中調(diào)試.NET Framework源代碼
最為關(guān)鍵的是pdb符號文件，沒得符號就調(diào)不了，對于符號我們從微軟的符號服務器上下載(默認就已配置)，還得有源代碼來調(diào)試。
點擊工具-選項-調(diào)試-常規(guī)，如果你之前沒有在該配置欄配置過，那么你就勾選 啟用源服務器支持 、啟用.net Framework源代碼單步執(zhí)行，然后將 要求源文件與原始版本完全匹配 給取消掉。
然后就是下載pdb符號文件了，如果想直接下載那么可以在調(diào)試-符號這欄 將Microsoft符號服務器給勾上 。如果想按需下載，那么在調(diào)試的時候，可以點擊調(diào)試-窗口 選擇 模塊/調(diào)用堆棧 來選擇自己想加載的去加載。
然后至 https://referencesource.microsoft.com/網(wǎng)站 點擊右上角下載源代碼。當你調(diào)試代碼的時候，會提示你無可用源，這個時候你再將你下載下來的源碼文件給瀏覽查找一下就可以了。
如何配置VS來調(diào)試.NET Framework源碼： https://referencesource.microsoft.com/#q=web 、 https://technet.microsoft.com/zh-cn/cc667410.aspx
還一種方法是，下載.NET Reflector插件，該插件可以幫助我們在VS中直接調(diào)試dll，這種方式操作非常簡單，不過該插件收費，具體的可以查看我之前寫過的文章(群里有該插件的注冊版)
.NET Core是什么
有丑才有美，有低才有高，概念是比較中誕生的。.NET Core就是如此，它是其它操作系統(tǒng)的.NET Framework翻版實現(xiàn)。
操作系統(tǒng)不止Windows，還有Mac和類Linux等系統(tǒng)， .NET的實現(xiàn) 如果按操作系統(tǒng)來橫向分割的話，可以分為 Windows系統(tǒng)下的 .NET Framework 和 兼容多個操作系統(tǒng)的 .NET Core。
我們知道，一個.NET程序運行核心在于.NET CLR，為了能讓.NET程序在其它平臺上運行，一些非官方社區(qū)和組織為此開發(fā)了在其它平臺下的.NET實現(xiàn)（最為代表的是mono，其團隊后來又被微軟給合并了 ），但因為不是官方，所以在一些方面多少有些缺陷(如FCL)，后來微軟官方推出了.NET Core，其開源在Github中，并被收錄在NET基金會(.NET Foundation，由微軟公司成立與贊助的獨立自由軟件組織，其目前收錄包括.NET編譯器平臺("Roslyn")以及ASP.NET項目系列，.NET Core，Xamarin Forms以及其它流行的.NET開源框架)，旨在真正的 .NET跨平臺。
.NET Core是.NET 技術(shù)框架組成在Windows.macOS.Linux系統(tǒng)下的具體的實現(xiàn)。
.NET Core是一個開源的項目，其由 Microsoft 和 GitHub 上的 .NET 社區(qū)共同維護，但 這份工作仍然是巨大的，因為在早期對.NET上的定義及最初的實現(xiàn)一直是以Windows系統(tǒng)為參照及載體，一些.NET機制實際上與Windows系統(tǒng)耦合度非常高，有些屬于.NET自己體系內(nèi)的概念，有些則屬于Windows系統(tǒng)api的封裝。 那么從Windows轉(zhuǎn)到其它平臺上，不僅要實現(xiàn)相應的CLR，還要舍棄或重寫一部分BCL，因而，.NET Core在概念和在項目中的行為與我們平常有些不同。
比如，NET Core不支持AppDomains、遠程處理、代碼訪問安全性 (CAS) 和安全透明度，任何有關(guān)該概念的庫代碼都應該被替換。
這部分代碼它不僅指你項目中的代碼，還指你項目中using的那些程序集代碼，所以你會在github上看到很多開源項目都在跟進對.NET Core的支持,并且很多開發(fā)者也嘗試學習.NET Core，這也是一種趨勢。
.NET Core指南https://docs.microsoft.com/en-us/dotnet/core/
.NET基金會：https://dotnetfoundation.org
.NET Core跨平臺的行為變更：https://github.com/dotnet/corefx/wiki/ApiCompat
微軟宣布.NET開發(fā)環(huán)境將開源 ：https://news.cnblogs.com/n/508410/
.NET Standard是什么
值得一提的是微軟還為BCL提出了一個標準，畢竟各式各樣的平臺，技術(shù)層出不窮，為了防止.NET在類庫方面的碎片化，即提出了一套正式的 .NET API (.NET 的應用程序編程接口)規(guī)范，.NET Standard。
正如上面CLS一樣，.NET Standard就類似于這樣的一個概念，無論是哪個托管框架，我們遵循這個標準，就能始終保持在BCL的統(tǒng)一性，即我不需要關(guān)心我是用的.NET Framework還是.NET Core，只要該類被定義于.NET Standard中，我就一定能在對應支持的.NET Standard的版本的托管框架中找到它。
.NET Standard： https://docs.microsoft.com/zh-cn/dotnet/standard/net-standard#net-implementation-support
.NET Standard開源代碼：https://github.com/dotnet/standard
.NET官方開源項目鏈接
現(xiàn)在我將給出.NET相關(guān)的開源項目地址：
參與.NET和.NET開源項目的起點：https://github.com/Microsoft/dotnet
Visual Studio
在文章最后，我還要簡單的說下Visual Studio。
通過上文得知，只需要一個txt記事本+csc.exe我們就可以開發(fā)出一個.NET程序，那么與之相比，.NET提供的開發(fā)工具VS有什么不同呢？
我們用記事本+csc.exe來編寫一個.NET程序只適合小打小鬧，對于真正要開發(fā)一個項目而言，我們需要文件管理、版本管理、一個好的開發(fā)環(huán)境等。而vs ide則就是這樣一個集成代碼編輯、編譯、調(diào)試、追蹤、測試、部署、協(xié)作、插件擴展這樣多個組件的集成開發(fā)環(huán)境，csc.exe的編譯功能只是vs ide中的其中之一。使用vside開發(fā)可以節(jié)省大量的開發(fā)時間和成本。
sln解決方案
當你用VS來新建一個項目時，VS會先為你新建一個整體的解決方案。這個解決方案表現(xiàn)為.sln和.suo后綴格式的文件，它們均是文本文件，對解決方案右鍵屬性可以進行相應的修改，也可以直接用記事本打開。
在sln中，定義了解決方案的版本及環(huán)境，如包含的項目，方案啟動項，生成或部署的一些項目配置等，你可以通過修改或重新定義sln來更改你的整個解決方案。
而suo則包含于解決方案建立關(guān)聯(lián)的選項，相當于快照，儲存了用戶界面的自定義配置、調(diào)試器斷點、觀察窗口設置等這樣的東西，它是隱藏文件，可刪除但建議不要刪除。
我們可以通過對比各版本之間的sln來修改sln,也可以使用網(wǎng)上的一些轉(zhuǎn)換工具，也可以直接點擊VS的文件-新建-從現(xiàn)有代碼創(chuàng)建項目來讓項目在不同VS版本間切換。
Visual Studio 2010 - # Visual Studio 4.0
Visual Studio 2012 - # Visual Studio 4.0
Visual Studio 2013 - # Visual Studio 12.00
Visual Studio 2015 - # Visual Studio 14
Visual Studio 2017 - # Visual Studio 15
項目模板
VS使用項目模板來基于用戶的選擇而創(chuàng)建新的項目，也就是新建項目中的那些展示項(如mvc5項目/winform項目等等)，具體表現(xiàn)為包含.vstemplate及一些定義的關(guān)聯(lián)文件這樣的母版文件。將這些文件壓縮為一個 .zip 文件并放在正確的文件夾中時，就會在展示項中予以顯示。
用戶可以創(chuàng)建或自定義項目模板，也可以選擇現(xiàn)有的模板，比如我創(chuàng)建一個控制臺項目就會生成一個在.vstemplate中定義好的Program.cs、AssemblyInfo.cs(程序集級別的特性)、App.config、ico、csproj文件
csproj工程文件
這里面，csproj是我們最常見的核心文件，CSharp Project，它是用于構(gòu)建這個項目的工程文件。
csproj是基于xml格式的MSBuild項目文件，其仍然是文本文件，可以打開并修改定義了的工程構(gòu)造的屬性，比如選擇性的添加或刪除或修改包含在項目中的文件或引用、修改項目版本、將其轉(zhuǎn)換為其它類型項目等。
MSBuild是微軟定義的一個用于生成應用程序的平臺(Microsoft Build Engine)，在這里為VS提供了項目的構(gòu)造系統(tǒng)，在微軟官方文檔上有著詳細的說明：https://msdn.microsoft.com/zh-cn/library/dd393573.aspx、https://docs.microsoft.com/zh-cn/visualstudio/msbuild/msbuild
項目屬性雜項
現(xiàn)在，簡單說明一下csproj文件的一些核心元素。我們用vs新建一個控制臺項目，然后對項目右鍵屬性打開項目屬性，在應用程序頁我們可以定義：程序集名稱(生成出來的程序集以程序集名稱作為文件名，相當于csc中的/out)、默認命名空間(每次新建類里面顯示的命名空間)、目標框架、應用程序類型、程序集信息(AssemblyInfo中的信息)、啟動對象(可同時存在多個Main方法，需指定其中一個為入口對象)、程序集資源(一些可選的圖標及文件)
1.在生成頁有：
2.在高級生成設置中有:語言版本(可以選擇C#版本)、調(diào)試信息(相當于csc中的/debug。選擇none則不生成任何調(diào)試信息，無法調(diào)試。選擇full則允許將調(diào)試器附加到運行程序，生成pdb調(diào)試文件。選擇pdb-only，自.NET2.0開始與full選項完全相同，生成相同的pdb調(diào)試文件。)、文件對齊(指定輸出文件中節(jié)的大小)、DLL基址(起點地址)
3.在生成事件選項中可以設置生成前和生產(chǎn)后執(zhí)行的命令行，我們可以執(zhí)行一些命令。
4.在調(diào)試選項中有一欄叫：啟用Visual Studio承載進程，通過在vshost.exe中加載運行項目程序集，這個選項可以增加程序的調(diào)試性能，啟用后會自動在輸出目錄生成{程序集名稱}.vshost.exe這樣一個文件，只有當當前項目不是啟動項目的時候才能刪除該文件。
IntelliTrace智能追溯
還要介紹一點VS的是，其IntelliTrace智能追溯功能，該功能最早存在于VS2010旗艦版，是我用的最舒服的一個功能。
簡單介紹，該功能是用來輔助調(diào)試的，在調(diào)試時可以讓開發(fā)人員了解并追溯代碼所產(chǎn)生的一些事件，并且能夠進行回溯以查看應用程序中發(fā)生的情形，它是一個非常強大的調(diào)試追蹤器，它可以捕捉由你代碼產(chǎn)生的事件，如異常事件、函數(shù)調(diào)用(從入口)、ADO.NET的命令(Sql查詢語句...)、ASP.NET相關(guān)事件、代碼發(fā)送的HTTP請求、程序集加載卸載事件、文件訪問打開關(guān)閉事件、Winform/Webform/WPF動作事件、線程事件、環(huán)境變量、Console/Trace等輸出...
我們可以通過在調(diào)試狀態(tài)下點擊調(diào)試菜單-窗口-顯示診斷工具，或者直接按Ctrl+Alt+F2來喚起該功能窗口。
當然，VS還有其它強大的功能，我建議大家依次點完 菜單項中的 調(diào)試、體系結(jié)構(gòu)、分析這三個大菜單里面的所有項，你會發(fā)現(xiàn)VS真是一個強大的IDE。比較實用且方便的功能舉幾個例子：
比如 從代碼生成的序列圖，該功能在vs2015之前的版本可以找到(https://msdn.microsoft.com/en-us/library/dd409377.aspx 、https://www.zhihu.com/question/36413876)
比如 模塊關(guān)系的代碼圖，可以看到各模塊間的關(guān)系
比如 對解決方案的代碼度量分析結(jié)果
比如 調(diào)試狀態(tài)下 函數(shù)調(diào)用的 代碼圖，我們可以看到MVC框架的函數(shù)管道模型
以及并行堆棧情況、加載的模塊、線程的實際情況
還有如進程、內(nèi)存、反匯編、寄存器等的功能，這里不再一一展示
鏈接
有關(guān)解決方案：https://msdn.microsoft.com/zh-cn/library/b142f8e7(v=vs.110).aspx
有關(guān)項目模板： https://msdn.microsoft.com/zh-cn/library/ms247121(v=vs.110).aspx
有關(guān)項目元素的說明介紹：https://docs.microsoft.com/zh-cn/previous-versions/visualstudio/visual-studio-2010/16satcwx(v%3dvs.100)
有關(guān)調(diào)試更多內(nèi)容：https://docs.microsoft.com/zh-cn/visualstudio/debugger/
有關(guān)代碼設計建議：https://docs.microsoft.com/zh-cn/visualstudio/code-quality/code-analysis-for-managed-code-warnings
有關(guān)IntelliTrace介紹：https://docs.microsoft.com/zh-cn/previous-versions/visualstudio/visual-studio-2010/dd264915(v%3dvs.100)
建議
我熱愛編程。
我知道大多數(shù)人對技術(shù)的積累都是來自于平常工作中，工作中用到的就去學，用不到就不學，學一年的知識，然后用個五六年。
我也能理解人的理想和追求不同，有的人可能就想平淡點生活。有的人可能是過了拼勁，習慣了安逸。有的人已經(jīng)認命了。
而我現(xiàn)在也每天飽滿工作沒多少時間，但在下班之余我仍然堅持每天都看一看書。
想學沒時間學，想拼不知道往哪拼。有埋汰自己腦袋笨的，有說自己不感興趣的。有明明躊躇滿志，但總?cè)觳遏~兩天曬網(wǎng)的。我身邊的朋友大多都這樣。
我想說，盡管我們每個人的境遇、思想、規(guī)劃不同，但我肯定大家大部分是出于生計而工作。
而出于生計，那就是為了自己。而既然是為了自己，那就別每天渾渾噩噩過，即使你因各種原因而沒有斗志。
編程來不得虛的，如果你沒走上管理，那么你的技術(shù)好就是好，不好就是不好，混不得，一分技術(shù)一分錢。自己不扎實，你運氣就不可能太好。
技術(shù)是相通的，操作系統(tǒng)、通信、數(shù)據(jù)結(jié)構(gòu)、協(xié)議標準、技術(shù)規(guī)范、設計模式，語言只是門工具。要知其然也要知其所以然，只知道1個梨+1個梨=2個梨，不知道1個蘋果+1個蘋果等于啥就悲劇了。
那怎樣提升自己？肯定不能像之前那樣被動的去學習了。
光靠工作中的積累帶來的提升是沒有多少。你不能靠1年的技術(shù)重復3年的勞動，自己不想提升就不能怨天尤人。
上班大家都一樣，我認為成功與否取決于你的業(yè)余時間。你每天下班無論再苦都要花一個小時來學習，學什么都行，肯定能改變你的人生軌跡。
比如你每天下班后都用一小時來學一個概念或技術(shù)點，那么300天就是300個概念或者技術(shù)點，這是何等的恐怖。
當然，這里的學要有點小方法小技巧的。不能太一條道摸到黑的那種，雖然這樣最終也能成功，并且印象還深刻，但是總歸效率是有點低的。
比如你從網(wǎng)上下載個項目源碼，你項目結(jié)構(gòu)不知道，該項目運用技術(shù)棧也不太了解，就一點一點的開始解讀。這是個提升的好方法，但這樣很累，可以成功，但是很慢。見的多懂的少，往往會因為一個概念上的缺失而在一個細小的問題上浪費很長時間。或者說一直漫無目的的看博客來了解技術(shù)，那樣獲取的知識也不系統(tǒng)。
我的建議是讀書，書分兩類，一類是 講底層概念的 一類是 講上層技術(shù)實現(xiàn)的。
可以先從上層技術(shù)實現(xiàn)的書讀起(如何連接數(shù)據(jù)庫、如何寫網(wǎng)頁、如何寫窗體這些)。在有一定編程經(jīng)驗后就從底層概念的書開始讀，操作系統(tǒng)的、通信的、數(shù)據(jù)庫的、.NET相關(guān)組成的這些...
讀完之后再回過頭讀這些上層技術(shù)的書就會看的更明白更透徹，最后再琢磨git下來的項目就顯得輕松了。
擊“PLC發(fā)燒友”，一起漲知識！
EasyBuilder Pro 主要是組態(tài)編寫威綸通觸摸屏畫面設計并和實際威綸通觸摸屏通訊連接軟件，可使用以太網(wǎng)或 USB 線來下載于 EasyBuilder Pro 組態(tài)畫面。
1 下載步驟
第一步：（打開瀏覽器，在網(wǎng)址地址欄寫入http://www.jcpeixun.com/進入技成官網(wǎng)—點擊下載中心）
第二步：（進入https://bbs.jcpeixun.com/thread-11948-1-1.html找到威綸通觸摸屏軟件點擊第六個即可下載）
友情溫馨提醒：下載要注意的是必須要登錄技成會員賬號才能獲取下載地址進行下載哦！
2安裝步驟
第一步：（在桌面找到下載好的安裝包，當然可能你們下載到其它存儲地方，我這里以桌面來講解，方法都一樣的。）
第二步：（解壓下載好的安裝包文件）
第三步：（解壓好后，打開文件夾鼠標選中setup安裝執(zhí)行文件并鼠標右擊以管理員身份運行）
第四步：（安裝語言選擇中文（簡體）后點擊確定）
第五步：（直接點擊下一步）
第六步：（選擇我接受協(xié)議，點擊下一步）
第七步：（默認安裝路徑C盤（系統(tǒng)盤），至少需要1.5G的安裝硬盤空間）
第八步：（直接點擊下一步）
第九步：（這里要注意了，一定要勾選（創(chuàng)建桌面圖標）換句說就是桌面快捷方式，不勾選到時候安裝好桌面會找不到快捷方式哦！然后點擊下一步）
第十步：（這里可以看到前幾步設置的一些參數(shù)信息，點擊安裝）
第十一步：（進入安裝過程，耐心等待即可）
第十二步：（安裝到這一步的時候提示是否要安裝驅(qū)動，點擊始終安裝此驅(qū)動程序軟件）
第十三步：（安裝完成，點擊完成即可）。
第十四步：（安裝完成后，在桌面會出現(xiàn)Utility Manager快捷方式）
第十五步：（鼠標雙擊打開Utility Manager快捷方式，進入軟件啟動對話框，鼠標點擊EasyBuilder Pro進入軟件界面）
來源：PLC發(fā)燒友，作者：技成培訓網(wǎng)-徐陳爽。
*請認真填寫需求信息，我們會在24小時內(nèi)與您取得聯(lián)系。
