Moonlight实现的跨越

    从深层次上看，Silverlight 1.1是.NET 2.0框架的一个延伸子集。许多功能已经被缩减，只留下那些在浏览器环境中有用的功能和一些被增加的额外的专门的应用程序编程接口。这本身对Mono项目就代表了一个有意思的挑战。它们并不是真的拥有管理多个运行时的资源，但是却想能够提供多个程序的化身。一个web用户不会仅仅因为运行一个小的applet而drag down 27 MB的Mono。

    解决方案就是Cecil，这是一个对于Mono项目具有战略意义的函数库。它能操作编译好的CIL（中间语言），并把修改后的程序集保存到磁盘中。基于Cecil之上的Linker工具能够创建同一个函数库的多个定义，在所有的编译已经完成的情况下创建合适的Moonlight库。这种优化的过程不仅仅可以移除不需要的部分函数库，而且可以增加需要的函数库，避免在最初源代码中的大量插入#ifdef的出现。目前来看，Moonlight的大小大约是8M或9M左右，大约是Mono的三分之一大。

    除了减少了应用程序编程接口（API）的大小外，在浏览器中使用Moonlight还可以带来另一个意义重大的挑战。通过网络实现并运行在浏览器中的应用程序必定会受到安全因素的影响，这一点是非常容易理解的。对于Silverlight本身来说，微软放弃了它们之前的.NET安全机制-代码访问安全（Code Access Security，CAS），而采用了另一种叫做CoreCLR的安全模型，这是一个简化过的安全模型，仅限于编写代码的人所做的是/否决策。

    由于移除了实现所有WPF功能的要求，Moonlight的安全模型包含三个代码访问级别：

   •透明（Transparent）代码
   •安全关键（Safe critical）APIs
   •关键（Critical）APIs

    所有的Silverlight应用是由安全透明的代码组成的；这意味着它们不能含有无法校验的代码，不能直接调用native代码。而safe critical APIs在Silverlight应用代码和critical APIs之间提供了一个桥梁。举个例子来说，访问文件系统将被认为是一个安全临界行为，因为它要求调用native系统。safe critical API实现了对文件系统访问的沙箱原则，对critical API进行封装，只允许符合规则的操作发生。