How do we file a change request on the xmlns in WinRT Xaml? RRS feed

  • General discussion

  • Hi,

    I am very disappointed with some aspects of WinRT.  Microsoft has made it incompatible with existing Silverlight and WPF applications, for no particularly apparent reason.  For example in WPF/Silverlight:


    In WinRT:

    You can absolutely argue that it is much nicer the second way. Unfortunately, some of us have hundreds of existing XAML files that need to be able to run under WinRT, that are now going to have to be duplicated on the basis of one or two lines. This is a maintenance nightmare.

    How can we encourage Microsoft to support the existing syntax under WinRT? I have no problem if there is also a new syntax, which should be backward ported to Silverlight and WPF, but in the meantime it would be nice to be able to use the existing syntax under WinRT. I see no reason at all why that couldn't be done. You could argue that I should just write a tool that runs prior to build, but unfortunately then you can't use the visual studio designer to see how it looks before building.

    How do we let Microsoft know that this concern for existing Silverlight and WPF developers?


    Thursday, March 8, 2012 8:58 PM

All replies

  • I've voiced my opinion on this numerous times, do this is a +1 from me.
    Thursday, March 8, 2012 9:53 PM
  • Hi Stefan, the WinRT XAML serves both managed and native worlds and the "clr-namespace" was confusing to our C++ brethren and causing concern.  Add to that is we don't support the "assembly=" concept because of WinRT guidelines (cannot have a namespace in a different assembly is the guideline, i.e. cannot have Foo.Bar namespace in an assembly of Baz.winmd).  This led us to a design change in this regard.  We understood this would be frustrating for folks. 

    One thing is that if we brought back support for "clr-namespace" it would *not* support the "assembly=" concept.  Given that, we feel that we're still in the same situation that you describe above and thus it isn't any better.

    As you note, you could do some #ifdef magic during build but would not work in the designer.  I'd love to vote up #ifdef in XAML editor :-). 

    Tim Heuer | Program Manager, XAML | http://timheuer.com/blog | @timheuer

    (if my post has answered your question, please consider using the 'mark as answer' feature in the forums to help others)

    Friday, March 9, 2012 1:00 AM
  • Tim,

    Thanks for your reply. I totally agree that the change in design is for the better. I do appreciate that designing a product of this complexity isn't easy.

    The problem is all my existing Xaml code is going to have to be duplicated and that's tens of thousands of lines across multiple solutions  So I make a change in the WPF or Silverlight version (and I'm single sourcing some projects in WPF, Silverlight, Windows Phone and soon WinRT - not all Xaml can be shared but a certain proportion is, particularly for some of my complex controls) and then I have to remember to go and make the same change in the WinRT source.  I already encounter occasional bugs because I make a change in WPF XAML which doesn't get pushed through to the Silverlight one, because different Xaml is required (e.g: I haven't yet stopped using Wpf Triggers because I'm not happy with the way that Visual States work in some cases), and it is extremely frustrating because often you don't realise there is a bug until you do a build of the other target some weeks later and have to remember what you changed in the other target.  This is only going to add to that complexity.  There may not be too many people in my situation, however.

    Personally, I would be extremely satisfied if "clr-namespace" was supported and the assembly was ignored (possibly even with a build warning).  It would work perfectly fine for me and help to maximize the amount of XAML can be shared.

    Yes, #ifdef would be nice, but it does create a bit of a mess in a situation like this where it has to be done in every file.  That is one of the early frustrating things about working with WinRT is that when you have hundreds of files in a solution, you have to go through every single one of them because there will be errors with any references to Wpf/Silverlight classes because they are in different namespaces in WinRT.  Not a huge problem once the initial conversion is done, but the end result is a mess of #ifdef at the start of every file.  I imagine that it will take me hours or days to convert even a single large project, just updating all namespaces, because every file has to be manually processed as they all use different namespaces in different orders.  Thank I goodness I'm using resharper which makes it a little bit easier. I can accept that is just one of that overheads of moving to WinRT , because once it's done once doesn't have to be done again, but with the XAML files it's going to be a constant battle to keep them all up to date.


    Friday, March 9, 2012 2:21 AM
  • Yes #if-def in XAML would be nice, but that doesn't really help us if that only gets added to metro-style apps (since we wouldn't be able to use that in older SL/WPF/WP7 projects)
    Friday, March 9, 2012 7:13 AM
  • How about updating WPF/SL/WP7 to support the "using:" syntax and updating WinRT to support the URI syntax? For SL/WPF we typically only use the clr-namespace syntax for the locally defined types (i.e. for types defined in the same assembly and therefore without the assembly=) and for types in other assemblies we use the URI syntax (i.e. XmlnsDefinition). Translating "clr-namespace" to "using" for WPF/SL/WP7 could even be a compile time thing that is only supported in the new version of VS/Blend (and available when using msbuild directly).

    BTW are these WinRT guidelines publicly available?

    Friday, March 9, 2012 1:36 PM
  • Andrew: I more often use the assembly= than referencing local. Anytime you make a control library you will have to do assembly for the templates. Anytime you consume controls/pages/classes/ViewModels/Models in other assemblies you will have to do this too. The patterns promote this style, rather than throwing everything into one big assembly (The Silverlight Toolkit controls alone forces people to use assembly). Also XamlReader.Load doesn't have a context of "local", so this also requires assembly to be specfied.

    Also your idea of doing the substitutions at compile time won't work, since XAML is not compiled in Silverlight (It's only WPF that does that).

    Lastly the XmlnsDefinition is not supported on WP7 (and AFAIK won't be due to perf reasons), so you can't define these for your custom controls like you can with SL.

    Friday, March 9, 2012 3:37 PM
  • I'm aware that WP7 doesn't support URI syntax which is why I stated "For SL/WPF" and didn't mention WP7 there. At least for us, very few templates/styles are shared between WP7 and WPF/SL - the small form factor just requires too many differences.

    As to consuming/referencing externally, if the URI syntax was supported then there wouldn't be a need to reference using assembly=. Also the SL Toolkit does define the XmlnsDefinition and XmlnsPrefix so you could use it (obviously only in SL since WP7 doesn't support it). 

    As to XamlReader.Load, yes I know it doesn't have a context of local but I believe that usage of XamlReader.Load is an edge case and could be handled in code (manipulate the xaml before loading it). I'm looking to get a majority of the sharable xaml shared and not worried about the very few cases where we use that. I think that at this stage the types of changes they will be willing/able to make are limited so I'm trying to be realistic.

    As to the substitutions it doesn't really matter if it is compiled. They could do some pre-build manipulations and use that - which technically we could do as well in a prebuild step but then every 3rd party developer would have to bake this in themselves when it would be better if VS/Blend handled this.

    Friday, March 9, 2012 3:59 PM