WPF 和 Silverlight 是否在冲突过程中？

Question

这两种已经相似的技术似乎正在合并为一种技术。 Silverlight 工具箱中有更多类似 WPF 的控件，而 WPF 现在有 Silverlight 的 VisaulStateManager。在这一点上，可以说 Silverlight 在可用主题数量方面甚至超过了 WPF。

这两种技术需要多长时间才能合二为一？富客户端应用和富浏览器应用之间的区别在于简单的编译时设置需要多长时间？

编辑

让我澄清一下我的问题。我意识到出于安全原因，任何浏览器应用程序都需要在“沙箱”中运行，并且我也理解保持浏览器插件尽可能小的愿望，但是这两种技术之间存在一些可能会被淘汰的细微差别在不影响这两个目标的情况下。例如，UI 控件和主题之间可能有更多的重叠。今天，您不能只在 WPF 应用程序中使用 Silverlight 主题，但如果让 Microsoft 实现这一目标，您会有多大的飞跃？

Answer 1

我认为它们永远不会合并为一个产品。微软有意在 Silverlight 之外留下了很多东西，以保持其占用空间小。然后是 Silverlight 在浏览器中运行时必须遵守的大量安全问题。当然，他们已经将其设计为可以在 PC 或 Mac 上运行（不幸的是，对于 .NET Framework 不能这样说）。

我很高兴看到 WPF 和 Silverlight 之间共享资源。他们从一开始就应该是相似的。因此，将 Silverlight 项目移植到 WPF 中相对容易。另一方面，从 WPF 迁移到 Silverlight 并不那么容易，因为 WPF 总是有更多的功能，但这只是野兽的本性。

更新：

所以你修改后的问题很有趣。如果 Microsoft 可以让您基本上翻转开关以在 Silverlight 类功能和 WPF 之间更改您的应用程序的行为，那将是很酷的。不过，他们将面临大量挑战，不仅是安全方面的挑战，还有一些轻量级 Silverlight 控件与功能丰富的 WPF 控件的基本行为。这些差异可能会使开发人员的事情进一步复杂化。

例如，在 WPF 中，文本框中有一个内置的多个撤消和重做系统。在 Silverlight 中没有这样的东西，所以我实际上不得不自己编写。为了让开发人员考虑到类似的事情，他们必须在应用程序中构建大量功能检查。

话虽如此，我认为您描述的编译时切换可能是可行的。但我仍然认为微软不太可能很快创造出这种能力。

Answer 2

XAML 和数据绑定可能会在两者之间变得更紧密
但框架的其余部分可能永远不会相同。
这一次，您无法使用 Silverlight 自动化 Office 应用程序。
这可能永远不会发生，除非 MS 决定打开某种形式的桥梁
在插件和 .NET Framework 之间。
安全性、一致性和出色的 UI 是 Silverlight 的主要驱动力。
如果您可以在 Windows 中做一些在 Mac 中无法做到的事情
失去一致性。

Answer 3

Silverlight 安装有自己为特定操作系统构建的库。作为开发人员，我们使用微软提供的可以在这些系统上运行的东西。 WPF 完全信任使用特定 windows api 调用的 windows 操作系统。所以我想说它们永远不会合并。

Answer 4

是的，我们会看到 WPF 和 Silverlight 变得越来越相似，如果合并的话？也许这并非不可能，但我们将看到的只是你所说的他们会更相似。因此，将来您不会实现 WPF 或 Silverlight，您将只实现 XMAL。