在何时使用WPF，何时使用Silverlight的问题上，很多人备感困惑。为项目选择正确的技术取决于应用程序的需求，以及WPF和Silverlight能力的不同之处。
Silverlight最初称为WPF/E（E来自于Everywhere的首字母），是面向运行在浏览器中的Web应用程序的一个WPF子集。如今，Silverlight以其快速的开发周期广为所知，且持续得到众人的关注，很多人认为它会成为微软未来的重要开发平台。
Mike Strobel认为微软对WPF/Silverlight的
考虑有一些混乱。
我认为最重要的事情，是提升WPF本身的影响。微软应该推动WPF成为富桌面应用程序的“核心”平台。然而恰恰相反，微软此时正推进Silverlight成为这样的平台。这会误导那些对两个平台都陌生，且不明白Silverlight不兼容标准.NET函数库的人。
某些人则认为WPF就快消亡了，不过Brian Noyes，一个微软区域技术领袖（Microsoft Regional Director）及微软最有价值专家（MVP），相信至少在未来几年不会出现这种情况。为了证明对WPF的这种看法，Noyes在如下几个方面强调了WPF和Silverlight之间的一些重要不同点：
| 特性 | WPF | Silverlight |
| 无限制 | 可访问用户文件夹：我的文档、我的照片、我的视频等 | |
| 具有很多选项，可访问打印对话框、打印队列等 | 需编程打印UI元素 | |
| 支持流文档和固定文档，有RichTextBox编辑支持，并能和流文档进行集成 | RichTextArea具备WPF的RichTextBox的大部分功能 | |
| 支持在按钮、超链接和菜单项上触发命令，键盘快捷键的输入可绑定到命令上，可实现路由命令 | 支持在按钮、超链接和上下文菜单项上触发命令，无输入绑定，无路由命令 | |
| 支持WCF的完整功能，能够调用和托管任何类型的服务，支持完整的安全选项和其他WS-*协议，支持REST和很多种低级通信方式 | 有限的WCF客户端功能子集，不能在客户端上暴露服务，支持不安全TCP或HTTP协议，比WCF客户端弱的双向通信（只能使用HTTP或不安全TCP），支持某些socket级的功能，在很多部署场景中必须考虑跨域访问问题。 | |
| 任何可序列化的对象 | 只支持文本 | |
| 任何东西 | 只能是文件 | |
| 有驱动、COM、Win32或通信协议支持的任何设备 | 网络摄像头、麦克风和有COM API或通信协议支持的设备 | |
| 键盘、鼠标、手写笔、触摸屏，基本没有任何限制 | 必须在信任提升的OOB中，全屏时才能获得完整的键盘支持 |
在WPF和Silverlight中还有一些不同的基本功能，这也可帮助大家来决定使用哪种技术。下面的例子，是一些开发人员做出选择的解释。
在规划我们的软件产品时，确实遇到了这样的问题。对于我们而言，决定因素是是否需要访问本地硬件，以及（或者）本地数据库。我们的主打产品，需要在本地100%地运行。我们需要在本地sql数据库中缓存信息，并且要访问一些硬件设备（GPS接收器、串口、WCF点对点通道、同步服务等等）。那个产品就由WPF来编写。而其他两个开发之中的产品，不用在本地保存信息（除了使用独立存储区），所以我们转而使用Silverlight。两个Silverlight产品都支持脱离浏览器安装方式。WPF应用程序的另外一个决定因素是对触摸的支持更加友好。感谢Surface团队，帮助我们在WPF应用程序中使用针对Windows Touch功能的Surface Toolkit。
另外一个开发人员，Jeff解释了为什么他的公司
一开始使用WPF开发的项目后来又转用Silverlight：
一年前，我们使用WPF开发了多媒体发送系统的自定义客户端。明年，我们将用Silverlight应用程序来替换这个WPF客户端。为什么？目前我们的大部分应用程序都是基于Web/浏览器的，不过我们也需要一个静态客户端来处理硬件交互和一些相对复杂的问题。现在，Silverlight具有的OOB模式意味着我们能够通过COM来连接本地硬件，这样问题就迎刃而解。为什么Silverlight在对战WPF中胜出呢――这是因为我们客户的运行环境的安装问题。不必自己处理操作系统的不兼容和功能差异，Silverlight都能正常运行。并且，现在升级也轻而易举，只用升级服务器，客户端就能自动升级。当然，WPF更加强大，不过很多东西我们用不上。