通俗易懂，什么是.NET?什么是.NET Framework？什么是.NET Core?（三）

风晓 2023-12-31 11:12:51  51621 赞同 0 反对 0

分类：资源

接上一篇通俗易懂，什么是.NET?什么是.NET Framework？什么是.NET Core?（二）

内存

应用程序域把资源给隔离开，这个资源，主要指内存。那么什么是内存呢？

要知道，程序运行的过程就是电脑不断通过CPU进行计算的过程，这个过程需要读取并产生运算的数据，为此我们需要一个拥有足够容量能够快速与CPU交互的存储容器，这就是内存了。对于内存大小，32位处理器，寻址空间最大为2的32次方byte，也就是4G内存，除去操作系统所占用的公有部分，进程大概能占用2G内存，而如果是64位处理器，则是8T。

而在.NET中，内存区域分为堆栈和托管堆。

堆栈和堆的区别

堆和堆栈就内存而言只不过是地址范围的区别。不过堆栈的数据结构和其存储定义让其在时间和空间上都紧密的存储，这样能带来更高的内存密度，能在CPU缓存和分页系统表现的更好。故而访问堆栈的速度总体来说比访问堆要快点。

线程堆栈

操作系统会为每条线程分配一定的空间，Windwos为1M，这称之为线程堆栈。在CLR中的栈主要用来执行线程方法时，保存临时的局部变量和函数所需的参数及返回的值等，在栈上的成员不受GC管理器的控制，它们由操作系统负责分配，当线程走出方法后，该栈上成员采用后进先出的顺序由操作系统负责释放，执行效率高。
而托管堆则没有固定容量限制，它取决于操作系统允许进程分配的内存大小和程序本身对内存的使用情况，托管堆主要用来存放对象实例，不需要我们人工去分配和释放，其由GC管理器托管。

为什么值类型存储在栈上

不同的类型拥有不同的编译时规则和运行时内存分配行为，我们应知道，C# 是一种强类型语言，每个变量和常量都有一个类型，在.NET中，每种类型又被定义为值类型或引用类型。

使用 struct、enum 关键字直接派生于System.ValueType定义的类型是值类型，使用 class、interface、delagate 关键字派生于System.Object定义的类型是引用类型。
对于在一个方法中产生的值类型成员，将其值分配在栈中。这样做的原因是因为值类型的值其占用固定内存的大小。

C#中int关键字对应BCL中的Int32，short对应Int16。Int32为2的32位，如果把32个二进制数排列开来，我们要求既能表达正数也能表达负数，所以得需要其中1位来表达正负，首位是0则为+，首位是1则为-，那么我们能表示数据的数就只有31位了，而0是介于-1和1之间的整数，所以对应的Int32能表现的就是2的31次方到2的31次方-1，即2147483647和-2147483648这个整数段。

1个字节=8位，32位就是4个字节，像这种以Int32为代表的值类型，本身就是固定的内存占用大小，所以将值类型放在内存连续分配的栈中。

托管堆模型

而引用类型相比值类型就有点特殊，newobj创建一个引用类型，因其类型内的引用对象可以指向任何类型，故而无法准确得知其固定大小，所以像对于引用类型这种无法预知的容易产生内存碎片的动态内存，我们把它放到托管堆中存储。

托管堆由GC托管，其分配的核心在于堆中维护着一个nextObjPtr指针，我们每次实例(new)一个对象的时候，CLR将对象存入堆中，并在栈中存放该对象的起始地址，然后该指针都会根据该对象的大小来计算下一个对象的起始地址。不同于值类型直接在栈中存放值，引用类型则还需要在栈中存放一个代表(指向)堆中对象的值(地址)。

而托管堆又可以因存储规则的不同将其分类，托管堆可以被分为3类：

1.用于托管对象实例化的垃圾回收堆，又以存储对象大小分为小对象(<85000byte)的GC堆(SOH，Small Object Heap)和用于存储大对象实例的(>=85000byte)大对象堆(LOG，Larage Object Heap)。
2.用于存储CLR组件和类型系统的加载(Loader)堆，其中又以使用频率分为经常访问的高频堆(里面包含有MethodTables方法表, MeghodDescs方法描述, FieldDescs方法描述和InterfaceMaps接口图)，和较低的低频堆，和Stub堆(辅助代码，如JIT编译后修改机器代码指令地址环节)。
3.用于存储JIT代码的堆及其它杂项的堆。

加载程序集就是将程序集中的信息给映射在加载堆，对产生的实例对象存放至垃圾回收堆。前文说过应用程序域是指通过CLR管理而建立起的逻辑上的内存边界，那么每个域都有其自己的加载堆，只有卸载应用程序域的时候，才会回收该域对应的加载堆。

而加载堆中的高频堆包含的有一个非常重要的数据结构表---方法表，每个类型都仅有一份方法表(MethodTables)，它是对象的第一个实例创建前的类加载活动的结果，它主要包含了我们所关注的3部分信息：

1包含指向EEClass的一个指针。EEClass是一个非常重要的数据结构，当类加载器加载到该类型时会从元数据中创建出EEClass，EEClass里主要存放着与类型相关的表达信息。
2包含指向各自方法的方法描述器(MethodDesc)的指针逻辑组成的线性表信息:继承的虚函数, 新虚函数, 实例方法, 静态方法。
3包含指向静态字段的指针。

那么，实例一个对象，CLR是如何将该对象所对应的类型行为及信息的内存位置(加载堆)关联起来的呢？

原来，在托管堆上的每个对象都有2个额外的供于CLR使用的成员，我们是访问不到的，其中一个就是类型对象指针，它指向位于加载堆中的方法表从而让类型的状态和行为关联了起来，类型指针的这部分概念我们可以想象成obj.GetType()方法获得的运行时对象类型的实例。而另一个成员就是同步块索引，其主要用于2点：1.关联内置SyncBlock数组的项从而完成互斥锁等目的。 2.是对象Hash值计算的输入参数之一。

上述gif是我简单画的一个图，可以看到对于方法中申明的值类型变量，其在栈中作为一块值表示，我们可以直接通过c#运算符sizeof来获得值类型所占byte大小。而方法中申明的引用类型变量，其在托管堆中存放着对象实例(对象实例至少会包含上述两个固定成员以及实例数据，可能)，在栈中存放着指向该实例的地址。

当我new一个引用对象的时候，会先分配同步块索引(也叫对象头字节)，然后是类型指针，最后是类型实例数据(静态字段的指针存在于方法表中)。会先分配对象的字段成员，然后分配对象父类的字段成员，接着再执行父类的构造函数，最后才是本对象的构造函数。这个多态的过程，对于CLR来说就是一系列指令的集合，所以不能纠结new一个子类对象是否会也会new一个父类对象这样的问题。而也正是因为引用类型的这样一个特征，我们虽然可以估计一个实例大概占用多少内存，但对于具体占用的大小，我们需要专门的工具来测量。

对于引用类型，u2=u1，我们在赋值的时候，实际上赋的是地址，那么我改动数据实际上是改动该地址指向的数据，这样一来，因为u2和u1都指向同一块区域，所以我对u1的改动会影响到u2，对u2的改动会影响到u1。如果我想互不影响，那么我可以继承IClone接口来实现内存克隆，已有的CLR实现是浅克隆方法，但也只能克隆值类型和String(string是个特殊的引用类型，对于string的更改，其会产生一个新实例对象)，如果对包含其它引用类型的这部分，我们可以自己通过其它手段实现深克隆，如序列化、反射等方式来完成。而如果引用类型中包含有值类型字段，那么该字段仍然分配在堆上。

对于值类型，a=b，我们在赋值的时候，实际上是新建了个值，那么我改动a的值那就只会改动a的值，改动b的值就只会改动b的值。而如果值类型(如struct)中包含的有引用类型，那么仍是同样的规则，引用类型的那部分实例在托管堆中，地址在栈上。

我如果将值类型放到引用类型中(如：object a=3)，会在栈中生成一个地址，在堆中生成该值类型的值对象，还会再生成这类型指针和同步块索引两个字段，这也就是常说装箱，反过来就是拆箱。每一次的这样的操作，都会涉及到内存的分布、拷贝，可见，装箱和拆箱是有性能损耗，因此应该减少值类型和引用类型之间转换的次数。
但对于引用类型间的子类父类的转换，仅是指令的执行消耗，几尽没有开销。

选class还是struct

那么我到底是该new一个class呢还是选择struct呢？

通过上文知道对于class，用完之后对象仍然存在托管堆，占用内存。对于struct，用完之后直接由操作系统销毁。那么在实际开发中定义类型时，选择class还是struct就需要注意了，要综合应用场景来辨别。struct存在于栈上，栈和托管堆比较，最大的优势就是即用即毁。所以如果我们单纯的传递一个类型，那么选择struct比较合适。但须注意线程堆栈有容量限制，不可多存放超大量的值类型对象，并且因为是值类型直接传递副本，所以struct作为方法参数是线程安全的，但同样要避免装箱的操作。而相比较class，如果类型中还需要多一些封装继承多态的行为，那么class当然是更好的选择。

GC管理器

值得注意的是，当我new完一个对象不再使用的时候，这个对象在堆中所占用的内存如何处理？
在非托管世界中，可以通过代码手动进行释放，但在.NET中，堆完全由CLR托管，也就是说GC堆是如何具体来释放的呢？

当GC堆需要进行清理的时候，GC收集器就会通过一定的算法来清理堆中的对象，并且版本不同算法也不同。最主要的则为Mark-Compact标记-压缩算法。
这个算法的大概含义就是，通过一个图的数据结构来收集对象的根，这个根就是引用地址，可以理解为指向托管堆的这根关系线。当触发这个算法时，会检查图中的每个根是否可达，如果可达就对其标记，然后在堆上找到剩余没有标记(也就是不可达)的对象进行删除，这样，那些不在使用的堆中对象就删除了。

前面说了，因为nextObjPtr的缘故，在堆中分配的对象都是连续分配的，因为未被标记而被删除，那么经过删除后的堆就会显得支零破碎，那么为了避免空间碎片化，所以需要一个操作来让堆中的对象再变得紧凑、连续，而这样一个操作就叫做：Compact压缩。
而对堆中的分散的对象进行挪动后，还会修改这些被挪动对象的指向地址，从而得以正确的访问，最后重新更新一下nextObjPtr指针，周而复始。

而为了优化内存结构，减少在图中搜索的成本，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代不受限制，最大可扩展至操作系统进程的整个内存空间。

比如第0代为256K，第1代为2MB。我们不停的new对象，直到这些对象达到256k的时候，GC会进行一次垃圾回收，假设这次回收中回收了156k的不可达对象，剩余100k的对象没有被回收，那么这100k的对象就被定义为第1代。现在就变成了第0代里面什么都没有，第1代里放的有100k的对象。这样周而复始，GC清除的永远都只有第0代对象，除非当第一代中的对象累积达到了定义的2MB的时候，才会连同清理第1代，然后第1代中活着的部分再升级成第二代...

第二代的容量是没有限制，但是它有动态的阈值(因为等到整个内存空间已满以执行垃圾回收是没有意义的)，当达到第二代的阈值后会触发一次0/1/2代完整的垃圾收集。

也就是说，代数越长说明这个对象经历了回收的次数也就越多，那么也就意味着该对象是不容易被清除的。
这种分代的思想来将对象分割成新老对象，进而配对不同的清除条件，这种巧妙的思想避免了直接清理整个堆的尴尬。

弱引用、弱事件

GC收集器会在第0代饱和时开始回收托管堆对象，对于那些已经申明或绑定的不经访问的对象或事件，因为不经常访问而且还占内存(有点懒加载的意思)，所以即时对象可达，但我想在GC回收的时候仍然对其回收，当需要用到的时候再创建，这种情况该怎么办？

那么这其中就引入了两个概念：
WeakReference弱引用、WeakEventManager弱事件
对于这2两个不区分语言的共同概念，大家可自行扩展百度，此处就不再举例。

GC堆回收

那么除了通过new对象而达到代的阈(临界)值时，还有什么能够导致垃圾堆进行垃圾回收呢？还可能windows报告内存不足、CLR卸载AppDomain、CLR关闭等其它特殊情况。

或者，我们还可以自己通过代码调用。

.NET有GC来帮助开发人员管理内存，并且版本也在不断迭代。GC帮我们托管内存，但仍然提供了System.GC类让开发人员能够轻微的协助管理。这其中有一个可以清理内存的方法(并没有提供清理某个对象的方法)：GC.Collect方法，可以对所有或指定代进行即时垃圾回收(如果想调试，需在release模式下才有效果)。这个方法尽量别用，因为它会扰乱代与代间的秩序，从而让低代的垃圾对象跑到生命周期长的高代中。

GC还提供了，判断当前对象所处代数、判断指定代数经历了多少次垃圾回收、获取已在托管堆中分配的字节数这样的三个方法，我们可以从这3个方法简单的了解托管堆的情况。

托管世界的内存不需要我们打理，我们无法从代码中得知具体的托管对象的大小，你如果想追求对内存最细微的控制，显然C#并不适合你，不过类似于有关内存把控的这部分功能模块，我们可以通过非托管语言来编写，然后通过.NET平台的P/Invoke或COM技术(微软为CLR定义了COM接口并在注册表中注册)来调用。

像FCL中的源码，很多涉及到操作系统的诸如文件句柄、网络连接等外部extren的底层方法都是非托管语言编写的，对于这些非托管模块所占用的资源，我们可以通过隐式调用析构函数(Finalize)或者显式调用的Dispose方法通过在方法内部写上非托管提供的释放方法来进行释放。

像文中示例的socket就将释放资源的方法写入Dispose中，析构函数和Close方法均调用Dispose方法以此完成释放。事实上，在FCL中的使用了非托管资源的类大多都遵循IDispose模式。而如果你没有释放非托管资源直接退出程序，那么操作系统会帮你释放该程序所占的内存的。

垃圾回收对性能的影响

还有一点，垃圾回收是对性能有影响的。
GC虽然有很多优化策略，但总之，只要当它开始回收垃圾的时候，为了防止线程在CLR检查期间对对象更改状态，所以CLR会暂停进程中的几乎所有线程(所以线程太多也会影响GC时间)，而暂停的时间就是应用程序卡死的时间，为此，对于具体的处理细节，GC提供了2种配置模式让我们选择。

第一种为：单CPU的工作站模式，专为单CPU处理器定做。这种模式会采用一系列策略来尽可能减少GC回收中的暂停时间。
而工作站模式又分为并发(或后台)与不并发两种，并发模式表现为响应时间快速，不并发模式表现为高吞吐量。

第二种为：多CPU的服务器模式，它会为每个CPU都运行一个GC回收线程，通过并行算法来使线程能真正同时工作，从而获得性能的提升。

我们可以通过在Config文件中更改配置来修改GC模式，如果没有进行配置，那么应用程序总是默认为单CPU的工作站的并发模式，并且如果机器为单CPU的话，那么配置服务器模式则无效。

如果在工作站模式中想禁用并发模式，则应该在config中运行时节点添加 <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工作模式来改善垃圾回收时的表现，但在实际开发中我们更应该注意减少不必要的内存开销。

几个建议是，减换需要创建大量的临时变量的模式、考虑对象池、大对象使用懒加载、对固定容量的集合指定长度、注意字符串操作、注意高频率的隐式装箱操作、延迟查询、对于不需要面向对象特性的类用static、需要高性能操作的算法改用外部组件实现(p/invoke、com)、减少throw次数、注意匿名函数捕获的外部对象将延长生命周期、可以阅读GC相关运行时配置在高并发场景注意变换GC模式...

对于.NET中改善性能可延伸阅读 https://msdn.microsoft.com/zh-cn/library/ms973838.aspx 、 https://msdn.microsoft.com/library/ms973839.aspx

.NET程序执行图

至此，.NET Framework上的三个重要概念，程序集、应用程序域、内存在本文讲的差不多了，我画了一张图简单的概述.NET程序的一个执行流程：

对于后文，我将单独的介绍一些其它杂项，首先是.NET平台的安全性。

.NET的安全性

.NET Framework中的安全机制分为基于角色的安全机制和代码访问安全机制。

基于角色的安全性

基于角色的安全机制作为传统的访问控制，其运用的非常广泛，如操作系统的安全策略、数据库的安全策略等等...它的概念就相当于我们经常做的那些RBAC权限管理系统一样，用户关联角色，角色关联权限，权限对应着操作。
整个机制的安全逻辑就和我们平时编写代码判断是一样的，大致可以分为两个步骤.

第一步就是创建一个主体，然后标识这个主体是什么身份(角色) ，第二步就是身份验证，也就是if判断该身份是否可以这样操作。

而在.NET Framework中，这主体可以是Windows账户，也可以是自定义的标识，通过生成如当前线程或应用程序域使用的主体相关的信息来支持授权。
比如，构造一个代表当前登录账户的主体对象WindowsPrincipal，然后通过 AppDomain.CurrentDomain.SetThreadPrincipal(主体对象);或Thread.CurrentPrincipal的set方法来设置应用程序域或线程的主体对象，最后使用System.Security.Permissions.PrincipalPermission特性来标记在方法上来进行授权验证。

如图，我当前登录账号名称为DemoXiaoZeng，然后通过Thread.CurrentPrincipal设置当前主体，执行aa方法，顺利打印111。如果检测到PrincipalPermission类中的Name属性值不是当前登录账号，那么就报错：对主体权限请求失败。

在官方文档中有对.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中是用来帮助限制代码对受保护资源和操作的访问权限。
举个例子，我通过创建一个FileIOPermission对象来限制对后续代码对D盘的文件和目录的访问，如果后续代码对D盘进行资源操作则报错。

FileIOPermission是代码控制访问文件和文件夹的能力。除了FileIOPermission外，还有如PrintingPermission代码控制访问打印机的权限、RegistryPermission代码控制操作注册表的权限、SocketPermission控制接受连接或启动Socket连接的权限。

对于这些通过代码来对受保护资源和操作的权限限制，也就是这些类名后缀为Permission的类，它们叫做 Permissions(权限)，都继承自CodeAccessPermission，都有如Demand，Assert，Deny，PermitOnly，IsSubsetOf，Intersect和Union这些方法，在MSDN上有完整的权限列表：https://msdn.microsoft.com/en-us/library/h846e9b3(v=vs.100).aspx

为了确定代码是否有权访问某一资源或执行某一操作，CLR的安全系统将审核调用堆栈，以将每个调用方获得的权限与要求的权限进行比较。如果调用堆栈中的任何调用方不具备要求的权限，则会引发安全性异常并拒绝访问。

图出自 https://docs.microsoft.com/zh-cn/dotnet/framework/misc/code-access-security

而除了Permissions权限，代码访问安全性机制还有权限集、证据、代码组、策略等概念。这些概念让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平台上的，因此它只限制于托管代码，我们可以直接调用非托管代码或进程通信间接调用非托管代码等多个手段来突破对托管代码操作资源的限制。

事实上，我们在平常项目中代码编写的安全机制(业务逻辑身份验证、项目框架验证)与这些平台级的安全机制没什么不同。我们可以理解为代码写的位置不一样，.NET安全机制是写在CLR组件中，而我们的安全机制是写在上层的代码中。这些平台级的标识更多的是和操作系统用户有关，而我们项目代码中的标识则是和在数据库中注册的用户有关，大家都是通过if else来去判断，判断的主体和格局不一样，逻辑本质都是相同的。

NET Core不支持代码访问安全性和安全性透明性。

.NET是什么

我在前文对.NET系统概述时，有的直接称.NET，有的称.NET Framework。那么准确来说什么是.NET?什么又是.NET Framework呢？

.NET是一个微软搭造的开发者平台，它主要包括：

1.支持(面向)该平台的编程语言(如C#、Visual Basic、C++/CLI、F#、IronPython、IronRuby...)，
2.用于该平台下开发人员的技术框架体系(.NET Framework、.NET Core、Mono、UWP等)，

1.定义了通用类型系统，庞大的CTS体系
2.用于支撑.NET下的语言运行时的环境：CLR
3..NET体系技术的框架库FCL

3.用于支持开发人员开发的软件工具(即SDK，如VS2017、VS Code等)

.NET Framework是什么

事实上，像我上面讲的那些诸如程序集、GC、AppDomain这样的为CLR的一些概念组成，实质上指的是.NET Framework CLR。

.NET平台是微软为了占据开发市场而成立的，不是无利益驱动的纯技术平台的那种东西。基于该平台下的技术框架也因为商业间的利益从而和微软自身的Windows操作系统所绑定。所以虽然平台雄心和口号很大，但很多框架类库技术都是以Windows系统为蓝本，这样就导致，虽然.NET各方面都挺好，但是用.NET就必须用微软的东西，直接形成了技术-商业的绑定。

.NET Framework就是.NET 技术框架组成在Windows系统下的具体的实现，和Windows系统高度耦合，上文介绍的.NET系统，就是指.NET Framework。

部署.net Framework ：https://docs.microsoft.com/zh-cn/dotnet/framework/deployment/deployment-guide-for-developers
.NET Framework高级开发：https://docs.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2008/29eafad8(v%3dvs.90)
.NET Framework源码在线浏览：https://referencesource.microsoft.com/

如何在VS中调试.NET Framework源代码

最为关键的是pdb符号文件，没得符号就调不了，对于符号我们从微软的符号服务器上下载(默认就已配置)，还得有源代码来调试。

点击工具-选项-调试-常规，如果你之前没有在该配置栏配置过，那么你就勾选启用源服务器支持、启用.net Framework源代码单步执行，然后将要求源文件与原始版本完全匹配给取消掉。

然后就是下载pdb符号文件了，如果想直接下载那么可以在调试-符号这栏将Microsoft符号服务器给勾上。如果想按需下载，那么在调试的时候，可以点击调试-窗口选择模块/调用堆栈来选择自己想加载的去加载。

然后至 https://referencesource.microsoft.com/网站点击右上角下载源代码。当你调试代码的时候，会提示你无可用源，这个时候你再将你下载下来的源码文件给浏览查找一下就可以了。

如何配置VS来调试.NET Framework源码： https://referencesource.microsoft.com/#q=web 、 https://technet.microsoft.com/zh-cn/cc667410.aspx

还一种方法是，下载.NET Reflector插件，该插件可以帮助我们在VS中直接调试dll，这种方式操作非常简单，不过该插件收费，具体的可以查看我之前写过的文章(群里有该插件的注册版)

.NET Core是什么

有丑才有美，有低才有高，概念是比较中诞生的。.NET Core就是如此，它是其它操作系统的.NET Framework翻版实现。

操作系统不止Windows，还有Mac和类Linux等系统， .NET的实现如果按操作系统来横向分割的话，可以分为 Windows系统下的 .NET Framework 和兼容多个操作系统的 .NET Core。

我们知道，一个.NET程序运行核心在于.NET CLR，为了能让.NET程序在其它平台上运行，一些非官方社区和组织为此开发了在其它平台下的.NET实现（最为代表的是mono，其团队后来又被微软给合并了），但因为不是官方，所以在一些方面多少有些缺陷(如FCL)，后来微软官方推出了.NET Core，其开源在Github中，并被收录在NET基金会(.NET Foundation，由微软公司成立与赞助的独立自由软件组织，其目前收录包括.NET编译器平台("Roslyn")以及ASP.NET项目系列，.NET Core，Xamarin Forms以及其它流行的.NET开源框架)，旨在真正的 .NET跨平台。

.NET Core是.NET 技术框架组成在Windows.macOS.Linux系统下的具体的实现。
.NET Core是一个开源的项目，其由 Microsoft 和 GitHub 上的 .NET 社区共同维护，但这份工作仍然是巨大的，因为在早期对.NET上的定义及最初的实现一直是以Windows系统为参照及载体，一些.NET机制实际上与Windows系统耦合度非常高，有些属于.NET自己体系内的概念，有些则属于Windows系统api的封装。那么从Windows转到其它平台上，不仅要实现相应的CLR，还要舍弃或重写一部分BCL，因而，.NET Core在概念和在项目中的行为与我们平常有些不同。

比如，NET Core不支持AppDomains、远程处理、代码访问安全性 (CAS) 和安全透明度，任何有关该概念的库代码都应该被替换。
这部分代码它不仅指你项目中的代码，还指你项目中using的那些程序集代码，所以你会在github上看到很多开源项目都在跟进对.NET Core的支持,并且很多开发者也尝试学习.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开发环境将开源：https://news.cnblogs.com/n/508410/

.NET Standard是什么

值得一提的是微软还为BCL提出了一个标准，毕竟各式各样的平台，技术层出不穷，为了防止.NET在类库方面的碎片化，即提出了一套正式的 .NET API (.NET 的应用程序编程接口)规范，.NET Standard。

正如上面CLS一样，.NET Standard就类似于这样的一个概念，无论是哪个托管框架，我们遵循这个标准，就能始终保持在BCL的统一性，即我不需要关心我是用的.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官方开源项目链接

现在我将给出.NET相关的开源项目地址：
参与.NET和.NET开源项目的起点：https://github.com/Microsoft/dotnet

.NET Core：https://github.com/dotnet/core
.NET Core文档：https://github.com/dotnet/docs
ASP.NET Core：https://github.com/aspnet/home
ASP.NET Core文档：https://github.com/aspnet/Docs
EntityFramework Core框架:https://github.com/aspnet/EntityFrameworkCore
ASP.NET Core MVC框架：https://github.com/aspnet/Mvc
EntityFramework6:https://github.com/aspnet/EntityFramework6
.NET Framework源码：https://github.com/microsoft/referencesource
.NET Core基类库：https://github.com/dotnet/corefx
.NET Core CLR：https://github.com/dotnet/coreclr
Roslyn编译器：https://github.com/dotnet/roslyn
MVC5、Web API2、Web Pages3框架源码：https://github.com/aspnet/AspNetWebStack
.NET Standard：https://github.com/dotnet/standard
KestrelHttpServer用于ASP.NET Core的跨平台Web服务器：https://github.com/aspnet/KestrelHttpServer
Visual Studio Code源码：https://github.com/Microsoft/vscode
一些优秀的.NET库、工具、框架、软件开源集合：https://github.com/quozd/awesome-dotnet
一些常用框架对ASP.NET Core和.NET Core的支持报告：https://github.com/jpsingleton/ANCLAFS
一些.NET下用于支持开发的开源项目集合：https://github.com/Microsoft/dotnet/blob/master/dotnet-developer-projects.md
微软出品的分布式框架orleans：https://github.com/dotnet/orleans
ML.NET 用于.NET的开源和跨平台机器学习框架：https://github.com/dotnet/machinelearning

Visual Studio

在文章最后，我还要简单的说下Visual Studio。

通过上文得知，只需要一个txt记事本+csc.exe我们就可以开发出一个.NET程序，那么与之相比，.NET提供的开发工具VS有什么不同呢？

我们用记事本+csc.exe来编写一个.NET程序只适合小打小闹，对于真正要开发一个项目而言，我们需要文件管理、版本管理、一个好的开发环境等。而vs ide则就是这样一个集成代码编辑、编译、调试、追踪、测试、部署、协作、插件扩展这样多个组件的集成开发环境，csc.exe的编译功能只是vs ide中的其中之一。使用vside开发可以节省大量的开发时间和成本。

sln解决方案

当你用VS来新建一个项目时，VS会先为你新建一个整体的解决方案。这个解决方案表现为.sln和.suo后缀格式的文件，它们均是文本文件，对解决方案右键属性可以进行相应的修改，也可以直接用记事本打开。

在sln中，定义了解决方案的版本及环境，如包含的项目，方案启动项，生成或部署的一些项目配置等，你可以通过修改或重新定义sln来更改你的整个解决方案。
而suo则包含于解决方案建立关联的选项，相当于快照，储存了用户界面的自定义配置、调试器断点、观察窗口设置等这样的东西，它是隐藏文件，可删除但建议不要删除。

我们可以通过对比各版本之间的sln来修改sln,也可以使用网上的一些转换工具，也可以直接点击VS的文件-新建-从现有代码创建项目来让项目在不同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使用项目模板来基于用户的选择而创建新的项目，也就是新建项目中的那些展示项(如mvc5项目/winform项目等等)，具体表现为包含.vstemplate及一些定义的关联文件这样的母版文件。将这些文件压缩为一个 .zip 文件并放在正确的文件夹中时，就会在展示项中予以显示。

用户可以创建或自定义项目模板，也可以选择现有的模板，比如我创建一个控制台项目就会生成一个在.vstemplate中定义好的Program.cs、AssemblyInfo.cs(程序集级别的特性)、App.config、ico、csproj文件

csproj工程文件

这里面，csproj是我们最常见的核心文件，CSharp Project，它是用于构建这个项目的工程文件。

csproj是基于xml格式的MSBuild项目文件，其仍然是文本文件，可以打开并修改定义了的工程构造的属性，比如选择性的添加或删除或修改包含在项目中的文件或引用、修改项目版本、将其转换为其它类型项目等。

MSBuild是微软定义的一个用于生成应用程序的平台(Microsoft Build Engine)，在这里为VS提供了项目的构造系统，在微软官方文档上有着详细的说明：https://msdn.microsoft.com/zh-cn/library/dd393573.aspx、https://docs.microsoft.com/zh-cn/visualstudio/msbuild/msbuild

项目属性杂项

现在，简单说明一下csproj文件的一些核心元素。我们用vs新建一个控制台项目，然后对项目右键属性打开项目属性，在应用程序页我们可以定义：程序集名称(生成出来的程序集以程序集名称作为文件名，相当于csc中的/out)、默认命名空间(每次新建类里面显示的命名空间)、目标框架、应用程序类型、程序集信息(AssemblyInfo中的信息)、启动对象(可同时存在多个Main方法，需指定其中一个为入口对象)、程序集资源(一些可选的图标及文件)

1.在生成页有：

条件编译符号(全局的预编译#define指令，不用在每个文件头部定义，相当于csc中的/define)
定义DEBUG/TRACE常量(用于调试输出的定义变量，如智能追踪的时候可以输出该变量)
目标平台(指定当前面向什么处理器生成的程序集，相当于csc中的/platform。选择x86则生成的程序集生成32位程序，能在32/64位Intel处理器中使用。选择x64则生成64位，只能在64位系统中运行。选择Any CPU则32位系统生成32位，64位系统则生成64位。注意：编译平台和目标调用平台必须保持一致，否则报错。生成的32位程序集不能调用64位程序集，64位也不能调用32位)、首选32位(如果目标平台是Any CPU并且项目是应用程序类型，则生成的是32位程序集)
允许不安全代码(unsafe开关，在c#中进行指针编程，如调换a方法和b方法的地址)
优化代码(相当于csc中的/optimize，优化IL代码让调试难以进行，优化JIT代码)
输出路径(程序集输出目录，可选择填写相对路径目录或绝对路径目录)
XML文档文件(相当于csc中的/doc，为程序集生成文档注释文件，浏览对方程序集对象就可以看到相关注释，VS的智能提示技术就运用于此)
为COM互操作注册(指示托管应用程序将公开一个 COM 对象,使COM对象可以与托管应用程序进行交互)

2.在高级生成设置中有:语言版本(可以选择C#版本)、调试信息(相当于csc中的/debug。选择none则不生成任何调试信息，无法调试。选择full则允许将调试器附加到运行程序，生成pdb调试文件。选择pdb-only，自.NET2.0开始与full选项完全相同，生成相同的pdb调试文件。)、文件对齐(指定输出文件中节的大小)、DLL基址(起点地址)

3.在生成事件选项中可以设置生成前和生产后执行的命令行，我们可以执行一些命令。

4.在调试选项中有一栏叫：启用Visual Studio承载进程，通过在vshost.exe中加载运行项目程序集，这个选项可以增加程序的调试性能，启用后会自动在输出目录生成{程序集名称}.vshost.exe这样一个文件，只有当当前项目不是启动项目的时候才能删除该文件。

IntelliTrace智能追溯

还要介绍一点VS的是，其IntelliTrace智能追溯功能，该功能最早存在于VS2010旗舰版，是我用的最舒服的一个功能。

简单介绍，该功能是用来辅助调试的，在调试时可以让开发人员了解并追溯代码所产生的一些事件，并且能够进行回溯以查看应用程序中发生的情形，它是一个非常强大的调试追踪器，它可以捕捉由你代码产生的事件，如异常事件、函数调用(从入口)、ADO.NET的命令(Sql查询语句...)、ASP.NET相关事件、代码发送的HTTP请求、程序集加载卸载事件、文件访问打开关闭事件、Winform/Webform/WPF动作事件、线程事件、环境变量、Console/Trace等输出...

我们可以通过在调试状态下点击调试菜单-窗口-显示诊断工具，或者直接按Ctrl+Alt+F2来唤起该功能窗口。