关于寄宿和AppDomain
微软开发CLR时，将它实现成包含在一个DLL中的COM服务器。
任何Windows应用程序都能寄宿（容纳）CLR。（简单来讲，就是CLR在一个DLL中，通过引用这个DLL，可以实现包含CLR）
CLR COM服务器初始化会创建一个默认AppDomain，这个AppDomain只有在进程终结时才会被销毁。
然而宿主程序还可以要求CLR创建额外的AppDomain。
因为创建进程开销很大，并且需要大量内存来虚拟化进程的地址空间。
所以人们就像可不可以在一个进程上运行多个程序呢。
于是就在进程上寄宿CLR，并除了AppDomain的概念。AppDomain是为了提供隔离而设计的。
当然原因不止如此，寄宿为应用程序提供了自定义和可扩展性的能力，然而这会导致一些恶意dll去破坏应用程序的数据结构和代码，还能利用安全上下文来访问本来无权访问的资源。
CLR的AppDomain可以解决这个问题，允许第三方的不受信任的代码在现有进程中运行，而CLR保证数据结构、代码和安全上下文不被滥用和破坏
AppDomain，看名字就知道：应用程序域。
以下为AppDomain的具体功能：
- 一个AppDomain的代码不能访问另一个AppDomain的代码创建的对象。这样就将两个AppDomain隔离开来，这种隔离使AppDomain很容易在进程中卸载，不会影响其它AppDomain正在运行的代码。
- AppDomain可以卸载。（前面提到过，默认的第一个AppDomain是不能卸载的）
- AppDomian可以单独保护。（每个AppDomain都会有自己的权限集）
- AppDomain可以单独配置。（每个AppDomain都会有自己的配置设置，主要影响CLR在AppDomain中的加载方式。涉及搜索路径、版本绑定重定向、卷影复制以及加载器优化）
一个进程上面运行一个CLR COM服务器，然后该CLR管理多个AppDomain，每个AppDomain可以有自己独立的程序。有的程序集是可以在AppDomain中共享的，比如MSCorLib.dll这种与.NET密不可分的类型，在CLR初始化时会被自动加载，有自己独有的loader堆去维护类型对象，且作为"AppDomain"中立的方式为所有AppDomain共享。
跨越AppDomain边界访问对象
前面讲到AppDomain就是为了隔离而设计的，且一个AppDomain的代码不能访问另一个AppDomain的代码。
然而要去做到也不是没有办法，为了实现两个AppDomain之间的通信。
按照AppDomain通信可以将类型分为三种：按引用封送类型，按值封送类型，完全不能封送的类型。
进程中可以有多个线程和多个AppDomain，然而它们不是一一对应的。
虽然一个线程一次只能执行一个AppDomain中的代码，但是一个线程可以执行一个AppDomain的代码后再去执行另一个AppDomain的代码，并且还可以查看自己在哪个AppDomain中。
然而这里由于感觉用不到关系，而且有点小复杂，所以就只领会了中心思想：
按引用封送：实际上就是AppDomain比如B传给另一个AppDomain比如A一个引用对象b，当执行b的函数时，实际上是线程又切回了B，调用完后再切回A。
按值封送：这个实际上就是将一个AppDomain中的对象序列化然后放到另一个AppDomain进行反序列化中。
卸载AppDomain
调用静态方法AppDomain.Unload即可。
卸载AppDomain会卸载其中的所有程序集，释放loader堆。
主要步骤：
- CLR挂起进程中执行过托管代码的所有线程
- 查看那些线程正在执行要卸载的AppDomain中的代码，有就强迫对应的线程抛出一个ThreadAbortException(线程中止异常)并恢复执行线程，这将导致执行遇到的所有的finally块以清理资源。如果没有代码捕捉到这个异常，那么finally就不会执行，但是线程会终止，但进程可继续运行。（其它所有未处理的异常我们在前面讲过会终止进程，而这里只会终止这个线程.
- 执行完第二步，所有的线程都会离开此AppDomain，CLR进入前面垃圾回收类似的标记阶段，标记垃圾。
- CLR强制执行垃圾回收，这些对象的Finalize方法被调用来正确清理占用的资源。
- CLR恢复所有线程的执行。
任何时候都只会有一个线程来调用Unload方法，不会有多个线程同时调用。
宿主如何使用AppDomain
控制台UI应用程序，NT Service应用程序，Windows窗体应用程序和WPF应用程序都是自寄宿（即自己容纳CLR）的应用程序。
它们都有托管exe文件，托管exe文件初始化进程后，会加载“垫片”（即MSCorEE.dll），垫片检查应用程序集的CLR头信息，决定加载哪个版本的CLR到进程中，CLR加载完后再次检查CLR头去茶砸后Main函数，然后调用该方法后程序才算真正启动起来。
再举一个例子，就拿ASP.NET来说，客户端请求一个Web应用程序时，如果是第一次请求，那么就ASP.NET要求CLR创建新的AppDomain，每个Web应用程序根据虚拟根目录来标识，然后让CLR将包含应用程序所公开类型的程序集加载到新的AppDomain中，创建实例，并调用其中方法。如果不是第一次请求就不会创建新的AppDomain。然而如果客户端请求不同的Web应用程序，也会创建新的AppDomain。貌似就说的是IIS里的那些不同的网站。
小总结：
到这一步，还是打算讲一下自己对这个东西的理解。
对于.NET的世界而言，都是在一个进程之上加载CLR（CLR COM服务器），然后在这个CLR上再加载不同的AppDomain。
对于我们平常写的那些简单用.net创建的程序如控制台程序，实际上也是在一个托管exe上再加载CLR，而此时会加载了默认的一个AppDomain。此exe可以作为一个宿主去加载更多的AppDomain，然而这就需要自己手动去加载了。
而对于那些不是.NET的非托管应用程序，也是可以加载CLR，而此时也会加载了默认的一个AppDomain，实际上它也可以作为一个宿主去加载更多的AppDomain。
可能有偏差，还望指正！
PS：
本章内容只择其精要写了一下，具体的AppDomain的玩法需要的时候再进一步深究。（话说回来，总有一种一辈子玩不到这个东西的感觉）