silverlight - XAML clr-namespace - 使用不兼容？

Question

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

WP8 想要:

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

WinRT 想要:

xmlns:vm="using:MyApp.ViewModels" 

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

有没有人找到解决方法？ XmlnsDefinition属性看起来可能会解决此问题，但 MS 将其从 WinRT 中移除。

Answer 1

此问题以及有限的解决方法在此处详细说明:http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj714088(v=vs.105).aspx

• XAML on Windows Phone 8 and XAML on Windows 8 is not binary compatible. As stated earlier, the controls you use to build your UI on each platform are similar. They are similar in name, behavior, and the programming interfaces, or syntax, they expose. However, they are implemented specifically for each platform.
• Namespace prefixes are different in XAML for Windows Phone 8 and XAML for Windows 8. This is illustrated by looking at the namespaces included in a basic page when you create it from scratch. [...] Comparing these namespace imports, you can see the subtle but significant difference in how a namespace is imported. In Windows Phone 8, imported namespaces are prefixed with clr-namespace:. In Windows 8 imported namespaces are prefixed with using:. This makes it difficult to use the same XAML, unless you can import namespaces using the same syntax.
• XAML doesn’t support conditional compilation. As shown in Conditional compilation with preprocessor directives, conditional compilation is a useful technique for handling platform differences by compiling in a code path that targets a particular platform, and another code path when compiling for another platform. This makes it difficult to share a XAML page between both platforms, because you can’t address the previous issue by simply conditionally compiling in namespace imports that use clr-namespace for Windows Phone 8 and using: for Windows 8.

This shouldn’t be seen as a complete roadblock for sharing between Windows Phone 8 and Windows 8. The clear guidance is to design and build your UI separately for each platform, embracing the design guidelines for each. It is technically possible to circumvent these obstacles. You could create your UI during page initialization from code. You could load platform-specific XAML from resources at runtime and inject it as a string into the page. However, none of these techniques scale and they make the construction of your core asset—how your app looks to your user—a tedious and error-prone task. Your code sharing investment will give you a much larger return further down your app stack, by trying to share app logic, data models, viewmodels, etc.

[...] One technique for sharing UI that can be of use in some circumstances is to isolate parts of your UI into user controls and attempt to share those. [...] However, due to the limitations called out at the beginning of this discussion, the technique is limited to basic user controls. In addition to those limitations, you should consider the guideline to always build your user experience to suit the target platform. Sharing XAML controls is possible but limited. A good candidate for this kind of sharing is UI you want to display in a pop-up window or other widgets that you want to share because they typically will be composed of basic UI elements with no complex XAML and with simple styling.