Silverlight XAML clr命名空间-使用不兼容？

在WinRT和WP8之间共享代码时：

WP8希望：

xmlns:vm="clr-namespace:MyApp.ViewModels" 

温特想要：

xmlns:vm="using:MyApp.ViewModels" 

这意味着您不能像在WP7、Silverlight和WPF中那样在项目之间共享XAML代码（如用户控件）

---

有人找到工作了吗

XmlnsDefinition

属性看起来可能会解决这个问题，但MS将其从WinRT中删除。

我只是在Windows Phone 8中做了一点工作，虽然编辑器默认情况下会将其转换为

clr名称空间

，但您仍然可以使用

将其更改为
，并且可以正常工作。
这个问题以及有限的解决方法，这里详细说明：


Windows Phone 8上的XAML和Windows 8上的XAML不兼容二进制文件。如前所述，用于构建UI的控件
在每个平台上都是相似的。他们的名字、行为和性格都很相似
它们公开的编程接口或语法。然而，它们是
专门针对每个平台实施
Windows Phone 8的XAML和Windows 8的XAML中的命名空间前缀不同。通过查看名称空间可以说明这一点
当您从头开始创建基本页面时，它包含在基本页面中。
[...]
通过比较这些名称空间导入，您可以看到细微但复杂的
名称空间的导入方式存在显著差异。在窗户里
电话8，导入的命名空间前缀为clr命名空间：。在里面
Windows 8导入的命名空间的前缀为using:。这就够了
很难使用相同的XAML，除非可以使用
相同的语法
XAML不支持条件编译。作为
显示在带预处理器指令的条件编译中，
条件编译是处理平台的一种有用技术
通过在针对特定对象的代码路径中编译而产生的差异
平台，以及为其他平台编译时的其他代码路径。
这使得两个平台之间很难共享XAML页面，
因为你不能简单地有条件地解决前面的问题
在命名空间中编译使用clr命名空间for Windows的导入
电话8和使用：适用于Windows 8

这不应该被视为是一个完整的障碍，以分享之间的信息
Windows Phone 8和Windows 8。明确的指导原则是设计和
为每个平台分别构建UI，包括设计
每一项的准则。从技术上讲，规避这些风险是可能的
障碍。您可以在页面初始化期间从创建UI
代码。您可以在运行时从资源中加载特定于平台的XAML
并将其作为字符串注入页面。然而，这些都没有
技术的规模和他们如何使你的核心资产建设
你的应用程序对你的用户来说是一项乏味且容易出错的任务。你的代码
分享投资会给你更大的回报
通过尝试共享应用程序逻辑、数据模型、视图模型，
等等

[…]一种在某些情况下可以使用的共享UI的技术
是将UI的各个部分隔离到用户控件中，并尝试共享
那些[…]但是，由于会议上提出的限制
在本讨论开始时，该技术仅限于基本用户
控制。除了这些限制之外，你还应该考虑
始终构建用户体验以满足目标的指导原则
站台。共享XAML控件是可能的，但有限。好的
这种共享的候选者是您希望在应用程序中显示的UI
您希望共享的弹出窗口或其他小部件，因为它们
通常由基本UI元素组成，没有复杂的XAML
而且造型简单

XAML共享只有通过在每个项目中维护XAML文件的单独副本才能在WP7/SL/WPF之间实现，所以“共享”有点用词不当。随着可移植类库的出现，这种情况实际上有所改变，尽管您仅限于使用所有目标平台上存在的类型和方法。在这种情况下，由于共享只是“复制文本”类型，因此您可以继续这样做（例外是您需要调整WinRT的“使用”）您不需要复制文件，只需将其作为链接文件添加，因此您只需维护一个文件。实际上，在WP7/SL/WPF中，如果您坚持使用基本控件，就可以共享XAML。诀窍是将主要xaml放在usercontrols中。然后，用户控件可以作为链接共享到每个VS项目中。然后在每个包含usercontrol的项目中定义一个页面或窗口或其他内容。