我认为最重要的事情，是提升WPF本身的影响。微软应该推动WPF成为富桌面应用程序的“核心”平台。然而恰恰相反，微软此时正推进Silverlight成为这样的平台。这会误导那些对两个平台都陌生，且不明白Silverlight不兼容标准.NET函数库的人。

在规划我们的软件产品时，确实遇到了这样的问题。对于我们而言，决定因素是是否需要访问本地硬件，以及（或者）本地数据库。我们的主打产品，需要在本地100%地运行。我们需要在本地SQL数据库中缓存信息，并且要访问一些硬件设备（GPS接收器、串口、WCF点对点通道、同步服务等等）。那个产品就由WPF来编写。而其他两个开发之中的产品，不用在本地保存信息（除了使用独立存储区），所以我们转而使用Silverlight。两个Silverlight产品都支持脱离浏览器安装方式。WPF应用程序的另外一个决定因素是对触摸的支持更加友好。感谢Surface团队，帮助我们在WPF应用程序中使用针对Windows Touch功能的Surface Toolkit。

一年前，我们使用WPF开发了多媒体发送系统的自定义客户端。明年，我们将用Silverlight应用程序来替换这个WPF客户端。为什么？目前我们的大部分应用程序都是基于Web/浏览器的，不过我们也需要一个静态客户端来处理硬件交互和一些相对复杂的问题。现在，Silverlight具有的OOB模式意味着我们能够通过COM来连接本地硬件，这样问题就迎刃而解。为什么Silverlight在对战WPF中胜出呢——这是因为我们客户的运行环境的安装问题。不必自己处理操作系统的不兼容和功能差异，Silverlight都能正常运行。并且，现在升级也轻而易举，只用升级服务器，客户端就能自动升级。当然，WPF更加强大，不过很多东西我们用不上。

根本的决定因素是，如果你的客户端应用程序主要是为了展现后端数据的前端界面的话——选择Silverlight 4已经完全足够。不过，如果你的客户端应用程序需要更紧密地和客户端机器集成，并且其他一些东西也要放在客户端的话，使用SL4的信任提升OOB模式也可能胜任，但是这样会给开发带来更多的挑战，也可能需要牺牲开发效率或功能来达成开发目标。你需要切切实实地做好前端需求分析，如果应用程序和客户端机器资源有大量的交互的，WPF仍旧是最好的选择，能让你的开发工作事半功倍。

我最近和微软的Ian Ellison-Taylor交谈过。Ian是一个直接向Scott Guthrie报告的总经理。在很多工作中，他的团队要开发Silverlight和WPF两者中的东西（以及RIA Services和其他很多东西）。我提到，我想在未来获得一些小道消息，他说可以为我提供一些。所以，他和我谈到了Silverlight和WPF合二为一的事情，并在随后互发了一些关于这个话题的邮件。

未来，Silverlight和WPF很可能会成为一个基于同一份代码的单一技术。毕竟，Silverlight是源自于所谓的WPF/E（E表示Everywhere），并以我们出乎意料的方式，弃用了这个丑陋的开发代号，而创造了一个美妙的产品名称（Silverlight）。