作实验前准备了点素材~~关于appDomain，可以理解为启动一个程序会有一个appDomain也就是应用程序域
1、appDomain是.NET框架独有的概念。很多人认为可以同进程的概念相同，我很不赞同：其一，“进程”是操作系统中的概念，在虚拟机/框架之类的体系中有着自己的定义和功能，显然这样理解appDomain是错误的；其二，“在应用程序域和线程之间没有一对一的关联，多个线程可以属于一个应用程序域，尽管给定的线程并不局限于一个应用程序域，但在任何给定时间，线程都在一个应用程序域中执行。”（.NET FrameWork SDK 中的描述），如果这里的“应用程序域”换成“进程”讲得通么？
2、隔离性。也不怪有人直接套解为进程，AppDomain有着代码执行隔绝的特性，就好像进程做的一样。appDomain的对象、代码可以认为相互隔离，甚至一个appDomain中的代码调用另外appDomain的对象（的数据或者方法等），需要类似DCOM中的“列集/散集”才可以进行（在类继承关系中appDomain类 继承自 MarshalByRefObject类）。每一个appDomain可以单独被调试、启动、停止，有着自己的默认的异常处理，一个appDomain崩溃了，不会影响其他的appDomain。可以理解为.NET的“逻辑进程”。
.NET中允许同一个应用程序的不同版本可以并存，消除了所谓的“dll hell”。通过创建不同的appDomain，我们可以让某个托管的程序集的1.0和2.0的版本同时执行（只要他们自身并不存在某个特定资源的非兼容性的存取访问）
3、安全性。由于代码隔离，可以防止某个危险代码对于其他的appDomain的影响。而且可以通过分配特定的安全分配，确定appDomain中的执行代码对于系统安全保护资源的访问。
4、独立性。每一个appDomain都由.NET的框架分配了专用的存储区（应用域局部存储）。任何对象都可以访问自己当前所在的appDomain的局部存储区，这个局部存储区被整个appDomain中的对象共享，也包括进入appDomain的线程（运行于同一个appDomain的线程可以通过这个局部存储进行通信）。
5、同进程、线程、程序集的关系。同进程属于多对一的关系，即一个进程中可以有多个appDomain，但是appDomain只能存在于某个进程中（显然，正如同上文：进程同appDomain属于不同的概念）。缺省情况下，如果你没有自己创建多个appDomain，一个进程启动后自动创建一个appDomain。而线程执行可以涉及多个appDomain，但某个特定时刻，线程仅存在于一个appDomain中，且线程可以进入其他的appDomain。某个程序集的某个实例属于具体的appDomain，由appDomain在自己的范围内加载，并按照程序集创建相应的对象。AppDomain是程序集的执行环境，同时程序集作为静态实体，可以被多个appDomain加载执行。
好现在做实验
以前我喜欢每次反射的时候都System.Reflection.Assembly.LoadFile().CreateInstance(),今天就琢磨了下如何能将得到的程序集加入到AppDomain.CurrentDomain，查了半天无果~~在最后测试了在System.Reflection.Assembly.LoadFile() 以后测试了下AppDomain.CurrentDomain.getAssemblys()发现已将包含了加入的程序集，
然后我直接用
AppDomain.CurrentDomain.CreateInstance(程序集名称,类);反射成功。
结论：
我猜 AppDomain.CurrentDomain.CreateInstance可以直接在当前内存开辟该类，省去了.LoadFile，和反射按道理来说，应该反射速度更快，更节省内存，并且可以使用AppDomain.CurrentDomain.SetData()，来传递数据~~相当于是一家人了哈哈~~
