CLR全面透彻解析: 使用CoreCLR编写Silverlight

Silverlight 2 包含对 Windows Presentation Foundation (WPF) UI 框架所做的大量 更改:新控件、丰富的网络 API 和数字版权管理 (DRM) 支持。Silverlight 2 中的一项主要更改就是能 够使用与 Microsoft .NET 兼容的语言编写 Web 客户端。在本文中,我将重点介绍 Silverlight 的开发核心:CoreCLR。

在过去的十几年中,我们已经拥有了许多不同的 Web 编程技术,从 CSS 到 ECMAScript 变体。其中 大部分技术都特定于 Web 编程任务,举例来说,通过编程 CSS 所学到的技术并不适用于其他领域。相比 之下,Silverlight 2 允许您使用适用于桌面编程的相同 .NET Framework 技术(如基类库、XAML 和 C# ),还允许您将这些技术直接应用到 Web 客户端应用程序。此外,也无需创建单独的 CoreCLR 开发环境 :您可以直接使用 Visual Studio 来设计、开发、调试和配置 C# 或 Visual Basic,就像使 用桌面应用程序一样。我们创建的 Silverlight 2 CoreCLR 可使 Web 编程像桌面编程一样丰富。

虽然拥有一个丰富的编程环境对开发人员很有好处,但用户并不想下载大型的浏览器插件。为了 使 Silverlight 适合用户使用,必须实现快速安装。我们已将 Beta 1 的安装大小缩减到 4.3MB,通过 宽带连接大约需要 6 到 10 秒钟即可安装。想想 .NET Framework 2.0 CLR 的两个主要核心部件 (mscorwks.dll 和 mscorlib.dll)的大小大约都等于 Silverlight 2 coreclr.dll 和 mscorlib.dll 相加的大小,这真是很了不起的成就。

深入了解 CoreCLR 引擎

自 2005 年 10 月发行 CLR 的 2.0 版本后即开始了 CoreCLR 的设计。它的两个主要设计目标是大小和兼容性:从编程人员的角 度来看,针对 CLR 的编码应该始终相同,而从用户的角度来看,下载必须非常小。由于 Silverlight 旨 在提供一组不同于桌面 CLR 的方案,因此,我们可以进行一些更改,以简化 CoreCLR 并允许我们缩减 Silverlight 的安装大小。但是,堆栈底部的一致性至关重要。行为差异(即使这些行为差异都正确)表 明堆栈上部有错误。

为了确保兼容性,我们在堆栈底部的各个组件中使用相同的代码。执行引擎 和虚拟机都是相同的。其中包括类型系统和元数据、垃圾回收器 (GC)、JIT 编译器、线程池以及运行时 引擎的其他核心部件。

但是,为了适应 Web 应用程序方案,进行了一些更改。例如,富 Internet 应用程序通常简单且运行时间短,JIT 编译器主要侧重于减少启动时间,而非执行更复杂的优 化操作。同样,服务器垃圾回收模式可以对使用相似分配模式的多个工作线程进行优化,而对 Web 托管 应用程序则行不通。因此,Silverlight 只包含针对交互式应用程序进行优化的标准工作站 GC。但是, 在 Silverlight 应用程序中使用 Microsoft 中间语言 (MSIL) 和元数据的方式与在针对桌面的托管应用 程序中的使用方式完全相同,而且应用程序的行为在用户的桌面上和在浏览器上一致。

事实上, Silverlight 并不打算取代桌面 CLR,这就引发了核心引擎中最大的变化:CoreCLR 将与桌面 CLR 进程 并行运行。过去,我们从来就不能在同一进程中运行 CLR 的两个版本。这是一个难题,原因有好几个, 其中一个是管理进程范围的状态:每个 CLR 实例都假定进程中只有一个 CLR,因而只有它可以处理其静 态数据。如果 CLR 1.1 和 2.0 中都包含 staticFoo 变量,而且在同一个进程中同时加载了这两个 CLR 版本,则任一版本都无法在不影响另一个 CLR 状态的情况下写入 staticFoo 变量。

虽然进程范 围的状态是最明显的问题,但在一个进程中并行运行两个 CLR 还会导致其他问题。例如,如果您同时运 行了两个 GC,如何防止其中一个 GC 挂起另一个 GC 的线程?此外,空间占用也存在问题:如果在一个 进程中加载多个 CLR,每个 CLR 都必须加载代码(这些代码可能都相同),并为其静态变量和托管堆留 出相应的空间。

在某些重要的情况下,托管 CoreCLR 需要与桌面运行时并行运行。如果 CoreCLR 和桌面 CLR 不能同时运行,我们将无法编写托管 Web 浏览器控件(该控件可以导航到使用 Silverlight 的网页)的桌面 Windows 窗体或 WPF 应用程序。若要解决这个潜在问题,只需在您的 Windows 计算机 上安装依赖于 CLR 的 Silverlight:每次安装 Windows XP SP2 和 Windows Vista 时,都会随操 作系统安装相当新的 CLR。但是,无论您的计算机上安装了哪种版本的 CLR(对于 Mac OS X 来说,即使 您的计算机上未安装任何 CLR),只要使所有 Silverlight 代码在 CoreCLR 上运行都必须确保绝对兼容 。因此,我们努力使 CoreCLR 可以与桌面 CLR 进程并行运行,我们相信经过我们的努力用户会获得更好 的 Silverlight 体验。

时间: 2024-10-31 22:17:36

CLR全面透彻解析: 使用CoreCLR编写Silverlight的相关文章

CLR全面透彻解析: .NET应用程序可扩展性

借助 Microsoft .NET Framework,编程人员便可轻松获取由不同开发人员和公司构建的组件,并将这 些组件集成到自己的应用程序中.但仅当已知哪些组件是构建基础时才能轻松实现上述过程.如果在构建 时对所需组件一无所知(对于加载项,通常会遇到这种情况),那么事情就会变得更加困难.开发人员在 扩展其应用程序时经常会遇到问题.例如,应将加载项存储在数据库中还是磁盘上?开发人员应考虑已知 接口的加载项以获得激活类型吗?使用 AppDomain.AppDomainManager 和 AppD

CLR全面透彻解析

目录 调整宿主 公开对象模型适配器.约定和加载项视图编写加载项协作加载项总结 您知道现在可以使用新的 Microsoft .NET 加载项框架 (System.AddIn) 创建可扩展的 Windows 窗体应用程序吗?在本期专栏中 ,我将修改 ShapeApp 绘图应用程序,以通过加载项框架公开其对象模型.这将 ,我就能够创建出在宿主应用程序上自动执行任务的加载项(自动化加载项). 另外,我还将讨论此方案以及现有解决方案中的常见问题. 如果您在开始前需要了解有关加载项框架的背景信息,请参阅 C

CLR全面透彻解析: 及早并经常评量性能,第2部分

在上期的"CLR 全面透彻解析"中,我强调要可靠地创建高性能的程序,您需要了解设计 初期所使用的各个组件的性能(msdn2.microsoft.com/magazine/cc424899).这就需要用到性能数据. 因此,测量是设计过程中不可或缺的一部分. 我还在那一期中介绍了一款名为 MeasureIt 的工具,利用它可以轻松地创建新基准,从而快速地收集 制定良好设计决策所需的数据.诸如 MeasureIt 之类的工具所提供的原始数字是极为重要的,另外,使 人们能够了解这些数字的基本含

CLR全面透彻解析:托管和本机代码互操作性

目录 托管和本机代码互操作适用哪种场合? 互操作技术:三种选择 互操作技术:P/Invoke 互操作技术:COM Interop 互操作技术:C++/CLI 互操作体系结构注意事项 API 设计和开发人员体验 互操作边界的性能和位置 生存期管理 托管和本机代码互操作适用哪种场合? 有关使用托管和本机代码互操作适宜时机的论述并不多,现有的论述也以自相矛盾者居多.有时,指南还缺乏实践体验做依据.因此,我先声明我编写的这个指南以我们互操作团队的实践经验为基础,它已向各类内部和外部客户提供过帮助. 在总

CLR全面透彻解析-F#基础

F# 是一种面向对象的新型函数编程语言,用于 Microsoft .NET Framework,已集成到本年度发行的 Microsoft Visual Studio 2010 中.F# 集简单.简洁的语法与高度的静态类型化于一身.这种语言能够胜任的任务从 F# Interactive 中的轻量探索性编程直到使用 Visual Studio 进行的基于 .NET Framework 的大型组件开发. F# 设计为完全在 CLR 上运行.作为一种基于 .NET Framework 的语言,F# 充分

CLR全面透彻解析: CLR 4中的生产诊断改进

在公共语言运行库 (CLR) 团队,我们有个小组专门提供 API 和服务,供其他人构建托管代码的诊断 工具.我们所拥有(就专用的工程资源而言)的两个最大组件是托管调试和分析 API(分别是 ICorDebug* 和 ICorProfiler*). 与其他 CLR 和框架团队类似,我们也只能通过努力开发应用程序实现我们的价值.例如,Visual Studio 团队会将这些调试和分析 API 用于他们的托管调试器和性能分析工具,还有大量第三方开发人员 在使用分析 API 构建工具. 在过去 10 年

CLR全面透彻解析:CLR中的线程管理

本专栏基于 CLR 线程系统和任务并行库的预发布版本撰写而成.所有信息均有可能发生变更. 当前进行的从单核体系结构到多核体系结构的技术变革带来了诸多好处.举例来说,在线程环境中, 如果有效使用多个线程,便可通过使用多个核和并行性提高性能,例如,使用多线程对数据库进行多个独 立查询的 ASP.NET 应用程序. 但是,使用多个核会带来一些新的问题.您可能会看到编程和同步模型变得更加复杂,您需要控制并 发,而要调整和优化性能将会更加困难.此外,对于影响并发应用程序性能和行为的许多新因素,我们还 不是

CLR全面透彻解析:大型对象堆揭秘

CLR 垃圾回收器 (GC) 将对象分为大型.小型两类.如果是大型对象,与其相关的一些属性将比对象 较小时显得更为重要.例如,压缩大型对象(将内存复制到堆上的其他位置)的费用相当高.在本月的专 栏中,我将深入探讨大型对象堆.我将讨论符合什么条件的对象才能称之为大型对象,如何回收这些大型 对象,以及大型对象具备哪些性能意义. 大型对象堆和 GC 在 Microsoft .NET Framework 1.1 和 2.0 中,如果对象大于或等于 85,000 字节,将被视为大型对象.此数字根据性能优化

CLR全面透彻解析: 及早并经常评量性能,第1部分

作为 Microsoft .NET Framework 公共语言运行库团队的性能架构师,帮助大家充分利用运行时 编写高性能的应用程序是我的职责所在.这无论是在 .NET 还是在其他语言中都不神秘--您 只需要在设计之初即考虑应用程序的性能问题即可.有很多应用程序在编写时根本未考虑性能问题.这通 常无关紧要,因为大多数程序的计算量相对较少,而且同和它们交互的人类相比,程序的计算速度要快得 多.遗憾的是,当真的需要程序具有较高性能时,我们却缺乏相关的知识.技能和工具来很好地实现这一 点. 在这里我将