Scott Guthrie谈Silverlight

• 文章来源: http://blog.csdn.net/hellothere/archive/2008/07/28/2726541.aspx
• 原文作者: 译者：程化
• 整理日期: 2008-09-23

Scott Guthrie：微软.NET研发部门的公司副总裁，负责Visual Studio开发工具，以及用微软.NET框架创建客户端和Web程序相关技术的研发。虽然身为高层管理人员，然而，Scott Guthrie保持了对技术细节相当的把握能力，只要看过他的博客，相信你对这点就会深有体会。

Charles：好的，我们又回到了Visual Studio世界。你是谁？这里都在发生什么事？

Guthrie：没问题。我的名字是Scott Guthrie，微软研发部总经理。基本说来，我管理着若干团队，他们创造了CLR、.NET Compact Framework、ASP.NET、Windows Presentation Foundation、Windows Forms、IIS、Commerce Server、Silverlight，以及开发Web 和Client的Visual Studio工具。

Charles：不可思议。啊，我们刚刚采访过你的老板，Soma，在Channel 9上谈了Orcas，恭喜你的工具发布了Beta 1版。

Guthrie：本周要出三个大东西。Orcas Beta 1，这已经发布到Web上了。和Windows Longhorn一起工作的IIS 7，明天，周三，应该就在Web上了，也许是你看到这个视频的前一周。Silverlight也要发布了，那应该是下周，也就是看到这个视频的那周。最近几周真是头疼。

Charles：让我们谈点关于Silverlight的东西，比如，我们退回一步，给我讲讲什么是Silverlight，怎么样？

Guthrie：没问题。Silverlight基本上提供了一个跨平台，跨浏览器的插件。它可以在Mac和Windows上工作。它可以在IE、Firefox、Safari上工作，将来还可以在Opera上 工作。基本上，它使你能够创建在浏览器中运行的，比现在丰富得多的用户体验。你可以加入媒体，这意味着非常丰富的视频和音频支持；你可以流化视频，在视频 上添加非常炫的效果，从而用非常非常丰富的方式在你的站点上把视频融合进来。它提供了非常丰富的矢量图形系统，这样你就可以做出很炫的图形，构建出用HTML无法实现的那种用户界面。它被设计为在一个Web页面中工作，所以很显然，你也能够使用HTML。我们将在MIX上宣布的一件重大事情是，我们将发布和Silverlight协同工作的.NET框架版本。你可以针对各种体验编程，不管是HTML、媒体还是矢量图形；不管是在客户端还是跨平台的方式。你可以使用任何托管语言，你可以用C#、VB，你可以用Python、JavaScript，你还可以用Ruby。

Charles：好的。回到问题上。首先，我想问的问题是，这需要一个大大的下载包，对吗？大家也会问，.NET框架怎么能够在Mac上运行？

Guthrie：好的，Silverlight有很多特性，如果你加上所有的图形特性，所有的媒体特性，所有的运行时特性，所有的语言特性，这是一个相当大的特性集。从.NET框架的角度来看，我们把LINQ包括了进来，我们还有网络协议栈，有线程模型，我们有基础类库，我们有许多特性。我们设计整体体验的方式是，把包含所有这些特性的下载包压缩到4M大小。随着经验增加，我们可能重新划分各部分，因此核心可能还会更小些。但是，我们下周发布的，包含了所有这些特性的Alpha版本，估计大小是4M，它被设计为花20秒或更少的时间就可以安装到系统上。基本上你有一个网页，点击一个链接，下载下来，这中间没有用户授权文件之类的东西，从开始到结束，都是非常用户友好的安装，基本上从开始下载到安装到系统中，我们希望花20到30秒，然后就可以用了。

Charles：这太让人吃惊了。从Windows的角度来看，我现在可以从某种程度上马上联想到你们如何裁剪基本类库来达到要求，也许用的是微型CLR，也许不是？

Guthrie：我们并没有使用微型CLR，实际上，不管是Mac还是Windows版本的Silverlight，其正式下载都不要求在你的系统上安装有.NET框架。它也不要求在你的系统上安装有某种媒体播放器。下载包中有在vanilla操作系统（译者注：Apple的操作系统）上运行所需要的一切，不用额外安装任何东西。

Charles：太令人惊讶了。

Guthrie：是的，我们做了许多工作。但是，我想要指出的另一件事是，我们随Silverlight一起发布的CLR版本是基于当前人们在使用的完整桌面版CLR。

Charles：哪个版本？Orcas？

Guthrie：啊，基本上是，你可以认为它来自Orcas源代码分支。基本上那是你运行Visual Studio，运行Blend，运行ASP.NET同样的浏览器，同样的类型系统，同样的即时编译器，垃圾收集器也是在Windows上发布的客户端版本，它给了你非常、非常、非常棒的性能。一般说来，我认为性能有多好依赖于你使用的测量基准，但是可以说在某些情况下，它的性能比JavaScript要高300到1000倍。听起来很夸张？但这是因为我们可以运行非常高效的代码，你知道，比起同类竞争性插件产品来说，要快10到15倍。所以，这是个非常快的执行引擎。而且，你有可用的、丰富的.NET编程环境。性能是一回事，然而，有丰富的特性也很重要，你可以用LINQ加入数据，你可以用WPF把数据绑定到界面控件上，你可以加入媒体，你可以在所有这些东西上应用向量变换，所有这些都在浏览器中，在沙盒环境下，这非常强大。

Charles：这简直不可思议地强大。

Guthrie：是的，我们非常兴奋，能够创建它和发行它，感觉非常好。

Charles：真酷，再次，我们回顾一下刚谈的东西，作为一个.NET开发人员，我可以用自己喜欢的.NET语言，写出非常有趣的编译后Web程序，使用Web UI，这叫做Silverlight。这简直不可思议，我认为这太非凡了，我想问的是，你们是怎么做到的？我是说，你是怎么让CLR和相关的技术可以运行在不同平台之上的，当然，CLR一开始就被设计为平台无关。那么，让我们谈谈这事，IL、别的什么？你们怎样做的？

Guthrie：好的。.NET框架中二进制代码的工作方式就是控制IL文件格式和引入的语义。CLR一直就被设计为基本上CPU中立、平台中立，所以，从核心架构的角度来看，我们做了很多工作。从运行时的角度来看，我们也做了很多工作，大约从.NET 2.0版本开始，我们就引入了一个类似于平台抽象层，作为框架的一部分，我们称之为平行层。在核心引擎中，任何时候我们需要进行OS操作时，我们都通过这个平台抽象层进行。这给了我们用不同层替换平行层的能力，基本上我们让顶层代码总是可以运转。我们架构CLR的基础，以及我们的目的，就是能够从单一源代码出发，产生出针对不同平台的二进制文件版本。包括针对不同版本的Windows，我们也可以使用同样的平台抽象层方法。所以，我们在这儿做了很多工作，给了我们很大的灵活性。这也意味着我们加进去的所有益处，CLR拥有的性能收益，甚至是为多核运行、多CPU运行所作的考虑，为客户端应用创建的超级高效的垃圾收集，所有这些好处，在Silverlight中都可以自动获得，这极大地有助于性能，极大地丰富了某些特性集。

Charles：有趣。你提到了架构，这就使事情深入了。那儿有一张白板。请你画给我们看看，画画Silverlight从架构上来看是怎样的，比如，你刚刚提到的东西至少已经有个轮廓了，CLR的架构，我们习惯在底层使用CLR和基础类库，但是，这里用的东西更紧凑些。我对了解这些东西很有兴趣，比如，这里的CLR和桌面系统的CLR不是一回事，对吗？

Guthrie：对，二进制文件不是一个，和桌面版本的二进制文件不同，但是，它们来自同一个代码树分支。我们确实有条件处理，在核心代码树上，我们可以为Silverlight的CLR，为完整桌面版本的CLR进行构造。是的，我们确实从Silverlight的CLR中排除了一些特性，比如，我们没有统一的角色，因为对跨平台应用和浏览器来说，这没有意义。我们也没有.NET 2.0中的服务器垃圾收集器，这是专门为服务器场景进行了优化的垃圾收集器，针对ASP.NET这样的东西，我们不需要发布它，因为在这里，只需要在浏览器中运行。而且，对于程序加载语义，也就是如何加载代码的机制，我们重写了相当一部分，我们没有Fusion，没有全局程序集缓存，所以，这里当然存在一些变化，但是，从类型系统的角度来看，从即时编译器的角度来看，以及从垃圾收集器的角度来看，基本上都来源于同样的代码树路径。在表层，基本上我们有裁剪过的完整版本.NET框架类库。你没有现在CLR拥有的15000到20000个类或API，有的是它的一个子集，经过针对构造基于浏览器程序进行特别裁剪的子集。但是，我们有集合、IO，以及线程，以及正则表达式引擎，以及XML协议栈，网络协议栈，我们也有同样的命名空间，同样的核心类型或类，它们都和现在你构造一个客户端应用程序所使用的相同。但是，我们在Silverlight包中没有一些东西，例如，NT服务器的API，或者那些对于在沙盒环境下运行的浏览器明显没有意义的东西。当你从UI的角度来看时，有基础的WPF的子集，UI框架，同样意义下的Canvas、XMAL、元素概念。这些概念都一样，命名空间也相同。我们的目标是：如果你针对这些子集编程，你构造出的代码将不光能够在Silverlight中运行，也能在完整的WPF应用中运行。在Silverlight中，我们努力要保证的一件大事就是：真正最大化你的技能集合。你了解现在的.NET，很好，你已经了解了要将自己的应用以非常丰富的方式运行在浏览器中是多么的容易，不需要学习一大堆新API。同样，一旦你学会了使用Silverlight的API，你就知道自己也可以将这些知识应用到完整的.NET框架应用程序上。所以，我认为从现有的.NET开发人员的角度来看，收获是巨大的，因为这意味着你可以在客户端运行.NET代码，在Web服务器上运行.NET代码，在数据库中运行.NET代码，在独立的WPF客户端运行.NET代码，你可以在所有这四个不同的层次使用相同的语言，相同的工具集。一旦你学会了如何使用泛型，泛型集合，了解了如何使用LINQ，或者知道如何使用线程，诸如此类，你可以把这些知识用到任何地方。

Charles：那么，插一句，在Silverlight中，你们确实支持Systme.threading？

Guthrie：我们确实有System.threading命名空间。这里有些小的裁剪，我们不支持完整的线程能力，比如，不支持创建线程。让我们回头看看，当前构造浏览器程序时有一类很棘手的事情，这类挑战是如何处理向服务器发出的回调，如何避免此时阻塞UI。如果你用的是JavaScript编程，一个挑战就是，你的代码运行于其上的线程就是浏览器用来绘制屏幕的线程。因此，如果你在JavaScript中写了一个无限循环，或者在JavaScript中使用了某种需要很长时间进行计算的东西，你的浏览器UI就不会被刷新。你的UI看起来就非常迟钝，这就给了浏览者一个暗示，表示你可能写了一个无限循环。当试图写负担沉重的Ajax应用时，这是个很大的挑战，因为你总是要回到服务器上取得更多数据，你知道，如果你对这种操作应对不当，它就会真的造成性能问题。我们在Silverlight中提供的一种能力是——在后台完成任务。这使用了你可能现在就已经了解的threading命名空间。它提供的能力让你可以这样说：喔，当数据返回时调用这些东西，获取一个可用线程，在上面进行操作。实际上，当需要进行绘制时，我们会发送一个完成信息，并且（手机响了起来……），对不起。

Charles：没关系，你也有个人生活，现在已经快7点钟了，我们还在让你接受Channel 9的采访。

Guthrie：这类场景，这类更加高级的场景，这类通向更加丰富的编程环境的场景，就包含在Silverlight中。从.NET的角度来看，这绝对不是微型CLR，绝对不只是有那么10个类看起来像是.NET，这就是.NET，并且给了你巨大的能力。

Charles：非常酷，太棒了。这点让人印象非常深刻。你可以获得像客户端已经安装了的CLR同样强大的能力，反过来说，在没有安装CLR的客户端上也能运行Silverlight。

Guthrie：是的，从我们的角度来看这是一个关键点，我们努力提供一种无摩擦的.NET部署，并且，让你可以使用HTML，使用丰富的图形，使用媒体，真正创建出某种目前无法做出的次世代体验。

Charles：让我来问这个问题，假设我在Windows上安装了Silverlight，出于某种原因，我们不去探讨具体原因，我之前没有安装.NET框架。然后我试图运行一个朋友给我的，要求.NET 2.0框架的应用程序。现在，我的问题实际上是：这些二进制程序都运行在怎样的沙盒中？典型说来，是CLR的程序装载器在起作用，Silverlight的装载器会找到它们吗？

Guthrie：沙盒是同一个，除非你启动Silverlight应用，否则和Silverlight一起发布的CLR不会被牵扯进来。这是个要非常小心处理的问题，我们想要避免偶然安装的东西与系统中其他东西发生冲突的任何机会。实际上，如果你需要，你甚至可以在同一个进程中既装入完整的.NET框架CLR，也装入Silverlight，这些代码会和平共处。

Charles：喔，这是重要的一点。

Guthrie：是的，你可以这样做，这和目前的情况不同。当前情况下，如果你把.NET 1.1和.NET 2.0装入同一个进程空间的话，会出问题。你绝对可以把Silverlight装入.NET 1.1或2.0存在于其中的进程。这是个很大的架构优势，它们不会冲突，不会造成任何问题。

Charles：你提到了WPF世界，你知道，WPF是对DirectX的抽象，这是为什么我们可以使用真3D的原因。很显然，Silverlight无法利用这个优势，因为DirectX无法在Mac上运行，对不对？

Guthrie：对，是这样。

Charles：所以，Silverlight可以处理矢量图形，但这不是真3D，或者是真3D？让我们谈谈这个。

Guthrie：我们得提到若干差异。其中之一是，Silverlight中有没有某些特定的3D图形API，比如，创建有若干物体的场景，放置光源和镜头，就像和Windows一起发布的WPF提供给你的那样。我们在Silverlight中没有那样的支持。主要原因是这要求有对性能说得过去的硬件设备加速的支持。在Silverlight中你可以相当程度地模拟3D。但是，在包中没有那种底层3D API。但是，你可以模拟。大家已经努力在用Flash，用Ajax之类的东西来模拟3D了，你可以用Silverlight模拟这些效果。你知道，如果你的样本能够满足3D的需要，你就可以这样做。但是，如果你想要像WPF提供的，超级丰富的3D图形，你应该用完整的WPF来做这件事。

Charles：当然。但是，你可以写出有趣的Silverlight类型的游戏。

Guthrie：喔，绝对如此，是的。

Charles：对Silverlight来说，我认为可以做到像比尔•盖茨总在说的那样：你喜欢做的事情是在Amazon上面用平常的方式进行购物，真的走在购物走廊中，这儿挑挑那儿拣拣。实际上，用这个技术，你可以开发出这种体验来。

Guthrie：你可以用Silverlight做到一点点。一个挑战是，通常说来，浏览器对3D支持得不好，浏览器通常不能很好地处理硬件加速。它们是用不支持硬件加速的图形API构造出来的。所以，要在浏览器中嵌入3D体验比较困难。如果很小心地处理在浏览器中的何处放置控件的话，你可以用WPF做到一点点。当然，你可以用浏览器外的独立程序来创造这种体验。我们想要为人们提供的一种能力是，让大家可以用Silverlight构造在浏览器中运行的应用程序，让程序可以工作在任何地方，我们想提供这种体验。如果你想做，你可以构造在浏览器外运行的，超级丰富的体验。你当然可以先做出一个Amzaon在线，然后在浏览器外提供Amazon购物的3D体验。

Charles：非常酷，现在我们提到了跨平台，现在支持的平台是Mac和Windows。这并不意味着其他的平台永远也不会得到支持，这并不意味着我们不会再支持其他任何东西。这是针对这个视频提的第一个问题，“对其他平台支持得怎样？” 你提到了合作伙伴，对其他平台的支持是可能的，大家可以实现这种支持？

Guthrie：是的，就支持的平台而言，我们当然没有任何宗教倾向。大家对我们有种先入为主的印象，有的人认为我们有所偏袒，但是我们没有。你知道，从团队的角度来看，当前我们仅仅选择针对Mac和Windows进行优化，主要因为这是两种当前在Internet上最常用的操作系统。它们占据了桌面操作系统的98％。我们也在观察移动设备系统。我们在观察如何能支持移动设备，从用户的角度来看，这是另一个领域，也许移动设备实际上是下一个能让我们接触到多数用户的操作系统领域。该领域有巨大的潜在用户。

Charles：那你们将来会用微型CLR来实现Silverlight，对不对？

Guthrie：啊，你知道，移动设备的挑战是，有120多种不同类型的操作系统，我们在密切关注这个领域，研究到底什么才是最好的实现方式。我想，很显然地，Linux和Clix等操作系统是值得考虑的。就支持哪些平台而言，我们并没有超级宗教化，基本上，我们挑出第一名，然后开始为其优化，给出我们的第一个版本，争取让我们的东西能接触到尽可能多的人。这就是我们为什么选择将Mac和Windows当作我们的目标平台的主要原因。

Charles：这很棒。

Guthrie：那么，未来会支持更多的平台，对未来会支持更多的平台我不会感到吃惊。但是，至少现在这样做，给了你创建体验，并且将这种体验传达给多达98％用户的能力。

Charles：那是很棒的一件事，而且你只需要写一次代码，而且你得用Visual Studio来写代码。

Guthrie：是的，这是很棒的一件事，我将在MIX上做关键演示，有个你可以看到的长长的视频。基本上，那是讲你可以用Visual Stuido Orcas写的那些很酷的东西。现在，假设你选择“File->New Project->Silverlight”，创建一个工程，你就得到了智能感知，你得到了调试支持，如果你愿意，你可以打开一个Blend表达式的工程，因为Blend和Visual Studio共享同样的工程格式，你可以用Blend来创建所有的UI，用Visual Studio来为其编程、调试。这样做行得通。在我们的发布中，实际上，我们甚至支持你从Visual Stuido对Mac进行调试。如果你在Visual Studio中创建的应用实际上运行在Mac上，你可以用“附加到进程上”的行为——敲入你Macintosh机器的IP地址，你会看到在Mac上所有运行托管代码的进程列表，你附加到Safari浏览器上，或Firefox浏览器上，设置一个端点，我们就可以工作了。这相当酷。

Charles：这简直不可思议。

Guthrie：这功能相当难做。但是，在本周就可以下载的版本中，这个功能被包含进去了。

Charles：太酷了。我是说，你们有没有通过和Apple合作才把这事搞定？你们是完全自己琢磨出来的吗？Mac是个相当封闭的操作系统，这是我为什么这样说的原因，在一定程度上来说，Mac相当封闭。

Guthrie：啊，是的，我们主要是靠自己完成的。你知道，我们有一些非常棒的工程师。当然，像在不同的操作系统间进行跨机器调试这种事，确实会带来一些拟真方面的挑战。但是，我们可以让所有东西顺利工作。从工程师的角度来看，最困难的事情是，各个浏览器有各不相同的插件感知机制。IE和Firefox不一样。有趣的是，Firefox和Safari使用了相同的接口API，它们实际上继承自古老的Netscape插件API。从表层的角度来看，事情都很好，你写一次代码，到处都可以用，但是，谈到实际上处理列表地址的语义，以及缓冲指针的语义，看起来Firefox和Safari是 非常不同的。从工程师的角度来看，这是最困难的，这些东西没有文档记录。比如，我们传递给你这个指针，但是，是不是还保留了在未来某时刻不告诉你就释放指 针的权利，或者，是你应该释放这个指针，还是我们释放这个指针？或者你以后再释放这个指针？由于各个浏览器不同的限制，我们在这里有若干的Bug需要追查。你知道，不光针对Firefox和Safari，也针对IE，试图找出浏览器与插件间的正确语义是很有趣的事情，但好处是，我们已经为你做了这个工作，在你的应用中，你不需要关心这事了。你可以在各个浏览器间获得一致的表现。

Charles：这让人惊叹。让我们谈谈，你们大家有没有碰到一些真正大的挑战，你最初产生这个点子时，你意识到了这将是非常艰难的一件事情吗？合作伙伴何时加入进来的？正如你之前提到的，始终都有合作伙伴。

Guthrie：合作伙伴始终都在。我们从早期就合作工作。我认为最困难的事实际上集中在下载包的大小上。你如何才能让下载包足够小。我们想要达到的目标是，最终发布的下载包，大小在2M到4M之间。当你想包括支持高清、全屏的视频Codec；当你想要包括支持MP3、WMA的音频Codec；当你想要丰富的矢量图形系统，让你能画图，能在任何分辨率下缩放图形；当你想要类型系统；当你想要能够运行Python、Ruby和JavaScript，你知道，当你逐渐增加这个列表时，控制大小很难办到。于是，一开始我们要做的很多事，基本上就是给人们一个预算，例如，“你有30K”。大家会说类似于“哇，你用30K做 不了任何有趣的事情”，你就必须亲自去见这些人，关起门来说，“很高兴和你谈话，抱歉，你不能够进入我们的产品。”人们的反应是，“哇，你说什么啊？”现 实的情况是，如果你真的非常专注，你可以把很多东西挤进很小的托管空间中。所以，我们重新实现了很多东西。我们确实在架构方面下了很多功夫，做了些重构。 我最喜欢的例子是：我们有一个颜色枚举对象，就像.NET中枚举颜色的数据类型那样。我是说，它包含了成千的颜色，深黑、浅灰，如此等等，这是个很长的列表。这个枚举占了多大的空间？我们开始计算，考虑到每个字符串所占的空间，每个属性的每个域所占的空间，为了这个颜色枚举我们用了差不多9K。有多少颜色是你真正需要用来做强类型属性的硬编码的？也许6种，或者8、9种，其他所有颜色都可以只用十六进制值来表示。这样依赖，9K缩 减到了几百个字节。这就是那种我们必须在所有地方进行的微级别决策。从运转项目的宏观层次上，我们持续不停地在关注：这是不是个很酷的场景？这是不是个很 酷的特性？你不能用这样多的空间，你必须让它更小些。这些都是很好的工程方面的挑战。通常说来，对绝大多数特性我们都能让它非常紧凑，但这只是从工程的角 度来说。这是个很艰巨的挑战。

Charles：绝对如此。现在让我来问你一个很好的问题（译者注：不是Charles在自吹，应该是在线看到的网友的问题）。如果我在Orcas中创建工程，例如，在Visual Studio中新建一个Silverlight工程，你知道，基本上说来，Visual Studio会让我可以引用我想用的任何库。假设我决定要引用一个Silverlight包不支持的库，这意味着什么？

Guthrie：很有趣。我们在第一个Alpha版本就提供这样好的工具支持的一个原因是，在Silverlight的CLR中，我们所用的程序集文件格式与完整桌面版本CLR相同。并且，我们使用相同的核心类库。有趣的事情是，Visual Studio提供给你的智能感知功能，从编译器的角度来看，是由和项目关联起来的被引用库程序集决定的。设想你创建了一个项目，你能不能说，“嘿，这儿有一个新版本的mscorlib，这儿有一个新版本的system.dll，这儿还有一个新版本的Silverlight.dll。”C#和VB的智能感知给不了你这样的智能感知。所以，我们对Silverlight做的事情实际上是创建了自己的mscorlib。它基于原来的mscorlib，但裁剪了一些在浏览器场景下没有意义的东西。我们让工具也支持这个mscorlib。同样，我们也模仿了调试API，如此一来对Silverlight，Visual Studio调试器也可以像平时那样附加到浏览器进程上。调试支持也内建在工具中。这极大地帮助了我们对工具方面的处理进行引导。很棒的一点是，如果你使用Silverlight的API子集来构造程序集的话，你就不光可以从Silverlight工程来引用，也可以从ASP.NET工程、WPF工程来引用，这没有问题。从Silverlight工程，如果你引用了，例如，一个用完整WPF构造的ASP.NET服务器控件，那么进行编译时你会看到编译器抱怨说它不知道这个API在哪儿。但是你知道，这至少比导致.NET崩溃强，而且这也不是某种完全不同的错误格式检查之类的东西。

Charles：这让人惊叹。我想我不得不提出来强调一下的是，你们让Silverlight甚至在设计期也遵循着沙盒原则。

Guthrie：是的。

Charles：这很重要，因为你知道，人们很容易在Visual Studio中添加引用，几乎可以引用任何东西。

Guthrie：我想，Silverlight提供给.NET开发人员的一个真正的机会是，如何在所有的不同领域都使用.NET。我认为，人们应该理解的一个重要点是，Silverlight没有替代HTML，它也完全不是设计来替代ASP.NET的，它真正的作用是使你可以在浏览器中写.NET代码。当你创建Silverlight应用程序的时候，你总是需要有一个服务器组件。任何地方都可以用.NET的真正优越的一点是：你可以XX Visual Studio，创建单个解决方案，你可以有一个ASP.NET工程，一个Silverlight工程，你可以在两者之间进行引用。Alpha版发布中有Visual Studio Orcas的插件，它给了你对Silverlight支持。它被设计为实际上可以配合ASP.NET和WCF Web Services工作。你可以ASP.NET工程中的Web Server引用与Silverlight工程关联起来，这样你的Silverlight工程就能够以很棒的强类型方式回调到ASP.NET应用中。你可以来回得数据，来回发送数据。你的Silverlight应用能够利用ASP.NET的角色管理系统，使用ASP.NET的成员。它可以很好地嵌入到你的ASP.NET应用中。作为MIX发布的一部分，我们还会发布一个包，它被称为ASP.NET的未来发布。它包含一些新的服务器端控件，特别设计来和Silverlight一起工作。这样一来，你可以非常轻松地用ASP.NET创建一个网页，你可以加上新的ASP XAML 控件，或ASP媒体控件，指向Silverlight工程，然后把整个ASP.NET工程就没事了。在ASP.NET应用中，不需要额外的代码。我们确实不光集中精力于努力创建Silverlight，同时也努力研究如何使Silverlight可以很好地加入到现存的.NET Web应用中。就Silverlight来说，我们得到了非常好的客户端－服务器对称性。

Charles：这非常酷，我必须要总结一下：我们在Channel 9上采访你已经有2、3次了，你支持的相关采访更多。我总是想要给你做做广告，因为你是首先看到.NET好处的人之一，尤其是服务器端，ASP.NET，是不是？你最初在ASP团队中，是这样吗？

Guthrie：啊，我启动了ASP.NET团队。当我们做ASP时，我在IIS团队中。

Charles：酷，你发起了战斗——这是托管代码，这东西非常优秀。现在我提这事，我不停唠叨这事的原因是，如果你看看自己所处的位置，我们在谈在基于浏览器的程序中写托管代码，而且不光在Windows上，还在Mac上，我认为这简直不可思议。我们往回看看，“哇，.NET真的已经是无处不在了”

Guthrie：是的，我认为，我的意思是，Silverlight真正的重大之处是，它真的打开了无穷多的可能性。实际上.NET有非常多的API，它们都很重要。许多API是为了使现存的场景能工作得更好。我认为Silverlight的有趣之处在于，以及从.NET的角度来看是个非常复杂的发布，它是关于使能某些现在就是无法做到的场景的。你知道，使能一类新的应用程序，在浏览器中运行，零摩擦的部署，运行在Internet上，你没必要担心是否某人已经安装了这个软件，是否有大量的再发布者的问题，或者，需要花20分钟安装某些东西，你仅仅需要点击URL，它就工作了，你知道，你确实可以在应用中加入更丰富的图形、媒体，以及类似于客户端的，用现在的JavaScript不可能做的计算。结果就是，构造了更加丰富的Channel 9，或者是下周举办的网球赛的更丰富的在线体验。我们有NetFlex等一大堆很酷的合作伙伴，它们展示给我们这是很棒的体验，你用当前的纯HTML或JavaScript就是无法做到。所以，它确实打开了跨平台和跨浏览器环境的机会。

Charles：太让人惊叹了。我是说，这是让人惊讶的工作。

Guthrie：我们正在到达目标……

Charles：你们正在到达目标，这非常酷，伙计，我认为，你刚刚提到，现在，我可以用Visual Studio这样的应用来创建，比如，三种不同的工程，对不对？我可以用来做我的Web工作，做我的站点，做我的服务器，我可以在同一个地方做所有这些，调试客户端和服务器。强大！

Guthrie：是的，你可以同时将调试器附加到浏览器客户端，以及ASP.NET服务器上。你可以想像这样一个过程：你的调试会话能自动跟踪从客户端向服务器回调，同样，因为LINQ同时支持服务器和客户端，你可以对SQL使用LINQ，对服务器上的实体使用LINQ，从数据库获取数据，创建分析后的结果，再将这些数据用Web Services发送到Silverlight。在Silverlight内部，你可以将数据绑定到WPF控件上，如果你想做，你还可以针对那些未连接的实体对象使用LINQ，对其做进一步的次级查询，再将数据绑定到其他东西上，然后你可以更新实体对象，将数据发送回服务器，更新数据库。这是Internet上在浏览器内进行的端到端集成，相当酷。

Charles：这意义太重大了。说起来我们真的很认真地在对待Web呢，是吧？Web 2.0了，伙计。

Guthrie：嗯，这样的应用会出现的，我想它会出现。你知道，从当前ASP.NET的背景来看，我认为，Silverlight真正可以让我们做的一件事情是，创建当前不可能的应用程序。在这个意义上，当前或者由于兼容性原因，或者由于过于复杂的原因，通常仅仅由于浏览器不支持的原因，有一类体验，有一类应用就是无法构造。Silverlight真的可以使你在这方面前进，开始琢磨这类工程，其结果当然会使用户获得愉悦的感受。

Charles：绝对如此。我们现在也使开发者很愉快，因为可以用托管代码了。

Guthrie：是的，非常希望从开发者的角度来看，这带来了很多乐趣。

Charles：绝对的。嘿，我确信你还有另一个会议，是不是？谢谢你的时间，我们真的很期待下周看到这个东西。

Guthrie：非常感谢。是的，我也非常期待。

Charles：好的，非常感谢，干得很棒，伙计。

Guthrie：非常感谢。