XAML Namespaces - Why Oh Why Is it "using:" Instead of "clr-namespace"?


  • Something's been bugging me for awhile now. I'm writing an application with both a Windows Runtime version as well as a WPF version for legacy users (sorry, but Win8 just doesn't have enough marketshare yet!)

    Thanks to PCL and MVVM, I can re-use 90% of the C# code. Yippiee!

    But the XAML is another story, and a HUGE part of that is the fact that in Windows Apps, identifying a XAML namespace requires "using:namespace.name" whereas in WPF, it's "clr-namespace:namespace.name"

    I would be able to share a huge proportion of my XAML files between my two app versions if not for this seemingly arbitrary difference between the two platforms.

    Why oh why was this done this way? Is there some technical reason MS does not wanting us sharing XAML files between platforms? Is there some best practice I'm violating by trying to do this? 

    By the way, for those who are interested, there is somewhat of a workaround. On the WPF side, if you keep your user-controls entirely in a different module (and they never refer to each other in their own XAML files), you can use XmlnsDefinition to define your module's XAML namespace as anything you want. So I can actually then refer to the uc's namespace as "using:namespace.name." That way it compiles properly both in the WPF and Windows App projects. That is indeed what I've been doing and now I'm sharing 90% of XAML as well. 

    Still, why oh why? Really, I'm not just trying to troll here. If there's a technical reason this was done and more importantly if there's a good reason I should not be attempting to share XAML code between WPF and App projects, I'd definitely like to know

    Thanks much.


    Tuesday, January 13, 2015 5:28 PM


All replies

  • If you search the posts from the developer preview era you'll find existing discussions on this.

    From a strictly technical sense, Windows.UI.Xaml is a native framework and doesn't use the clr. It is

    projects into managed languages so you can use the clr with it, but that is optional.

    Tuesday, January 13, 2015 6:37 PM
  • Interesting, thanks for the response Rob. I guess it comes down to this - did MS make a judgment that sharing XAML between WPF projects and Store projects was just not something that was going to be given any kind of consideration? Just seems odd given the overwhelming overlap between the APIs. 

    I'll take a look at the dev preview discussions too. Thanks again.

    Tuesday, January 13, 2015 6:42 PM
  • The thread I was thinking of is at https://social.msdn.microsoft.com/Forums/windowsapps/en-US/7f492c62-4844-40e6-960c-27cbf076b812/how-do-we-file-a-change-request-on-the-xmlns-in-winrt-xaml?forum=winappswithcsharp

    The UI design of WPF and of Windows Store apps is generally different enough that there wouldn't be a large overlap in Xaml. You'll generally want different layouts, many of the standard controls are different, and there are several other Xaml features which differ between WPF and Windows.UI.Xaml.

    It would be very useful to be able to share Xaml for custom controls and UserControls, and conditional compilation (#ifdef) for Xaml is a frequently heard request (although I don't see that obviously on http://wpdev.uservoice.com , but I may just be failing at search).

    I know some people do pre-processor tricks to fake this at the expense of being able to use the designer, but it's neither supported nor something I've looked into deeply.

    Tuesday, January 13, 2015 7:56 PM