How can we improve the Windows dev platform?

Add Markup Extensions to (and Improve) WinRT Xaml System (System.Xaml Parity)

Much effort was made in WPF Xaml Serialization to decouple it from the presentation assemblies and moved into its own assemblies, System.Xaml, and System.Windows.Markup.

This Xaml System had it's own serialization/deserialization mechanism in XamlServices class. Furthermore, this Xaml system had a very powerful component/concept that is conspicuously absent in WinRT: Markup Extensions.

Markup Extensions are found in the following Xaml Systems:
- Silverlight 5
- Xamarin.Forms (notably NOT a Microsoft technology, but recognizes their power nonetheless)

This feature is to ask for Xaml serialization featureset parity with WPF/System.Xaml. That means:
- Custom Markup Extensions
- XamlServices.Load and Save
- All default system markup extensions "{x:Null}, {x:Static}, etc." found in WPF/Silverlight5.
- IProvideValueTarget interface
- INameScope interface
- ... and more!


345 votes
Sign in
or sign in with
  • facebook
  • google
    Password icon
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Mike-EEE shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    An always happy Friday as I just got the TFS complete email :) As this hasn’t hit an insider preview SDK, i’m going to mark this still as “working on it” still BUT … this will be coming to an insider build near you!

    This item heart is markup extensions. There is one item that will not be there however that is relevant to markup extensions, IServiceProvider. I created a new item for that but we are working on this item []. We have created a new one and we are working on that (that includes IProvideValueTarget and INameScope) but feel we have enough to ship this and mark this larger work item done and we do point out in reference to more work items need to happen, namely the work around IServiceProvider.

    Also XamlServices.Load / Save isn’t directly related to markup extenstion so we’re viewing that as out of scope. Also per documentation, System.Windows.Markup.XamlReader and XamlWriter are the preferred ways to do this, which are in UWP. ( and


    Sign in
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      • Mike-EEE commented  ·   ·  Flag as inappropriate

        @Clint... thanks, I know that Christophe is indeed part of the Xaml team. I spoke with him on the phone a few weeks ago and was really impressed with his professionalism. I say this as the poor guy essentially listened to me b*tch his ear of for over an hour as we discussed the UWP group. Or I should say, *I* complained about the UWP group. :)

        It was during this phone call that I sadly learned that the examples of markup extensions that I and others provided Tim nearly two years ago were not captured or maintained, so Christophe had to make the request of shame to find them *yet again*. I try to be supportive, but I am sure you can understand the frustration of:

        1) Having to explain to a principle manager of a MSFT UX manager the benefits and power of markup extensions.
        2) Providing examples upon request.
        3) Discuss these markup extensions and more on a phone call.
        4) Wait two years. ;)
        5) Having to explain to the principle design staff of MSFT UX the benefits and power of markup extensions (again).
        6) Having to provide examples of markup extensions once again, which are literally saturated in WPF documentation, examples, and projects throughout the ecosystem.

        You will have to forgive me if I am not feeling the passion here. No other group that has designed a flavor of Xaml has demonstrated such friction to employ a feature that is so obvious and available in literally every other version of Xaml you can find.

        I hope you find this as constructive, and I hope even more you can understand the frustration here. To show I am a good sport, I finally did a little digging and was able to yield one example. Twitter is very difficult to navigate so I am not able to find the others at the moment, but I know they were provided. You will have to forgive me for not feeling the desire to spend more time than I have to as I am not confident it will matter in any meaningful way:

        If you read parts of that discussion, it's pretty shocking to see how similar the discussion there is much like the discussion here... two years later. ;)

        Finally, you really should be on the Xaml Standard repo. There is not a lot of love there for UWP, I'm afraid. It's all WPF, Avalonia, and even Noesis. I am holding out hope that now that we have this platform we can land on a, well, standard, that we all can finally be proud of, once again.

      • Mike-EEE commented  ·   ·  Flag as inappropriate

        I appreciate the reaching out for communication and engaging your users, Christophe! But I do have to be honest and say that your request for examples is disheartening. It would seem that this isn't necessary. They were there in WPF, and also Xamarin.Forms uses a few of them as well. You're basically asking "how can we limit the creativity and possibilities of the users that would like to consume our API?"

        It's important to note that every flavor of Xaml with markup extensions uses IServiceProvider and/or these services in some form or another. Even Noesis -- which is quickly becoming a popular cross-platform Xaml alternative in the vacuum that UWP has created -- utilizes these.

        Now with the advent of the Xaml Standard, it would seem that these services will become a staple moving forward.

        We welcome you and your team to join (and listen to) the community in an open, transparent dialogue, while relying less on being dependent on personal emails, which always seems like a request straight from 1985. ;)

      • AdminChristophe Philippona [MSFT] (Admin, Windows Developer) commented  ·   ·  Flag as inappropriate

        Thanks for the feedback. We're working towards solving .Net concepts like IServiceProvider in UWP. We would like to help you reuse as much of your code and libraries as possible.

        Can you share some examples of scenarios where you use IRootObjectProvider, IXamlTypeResolver... and the other IServiceProvider services? These examples help us validate that we are moving towards our goal. Examples of non DOs that you use XamlSetMarkupExtensionAttribute for would help as well.

        Please feel free to email me directly with samples/examples

      • Dmitry commented  ·   ·  Flag as inappropriate

        >> Our goal here is to support ProvideValue like WPF does with the one exception of IServiceProvider, which is a .NET concept that we can't quite solve yet in the UWP platform (also working on these type of things)

        It has not much sense of MarkupExtension without essential interfaces like IXamlTypeResolver (no way to resolve type = no way to implement even the simplest x:Static-like extension), IProvideValueTarget (no way to know where is MarkupExtension being applied), IRootObjectProvider (no way to get Xaml root object) and so on...

        I have a Silverlight/WPF project which uses MarkupExtensions extensively first of all to provide SL/WPF cross platform possibilities to write single Xaml code for both platforms. Without custom Markup extensions I can't even think of using UWP.

        In addition to IServiceProvider, I'd also like to see XamlSetMarkupExtensionAttribute, which allows setting MarkupExtensions on objects which do not derive from DependencyObject (WPF feature which you also could forget)

      • Andrew Thompson commented  ·   ·  Flag as inappropriate

        @Tim - just sent you an email. Thanks for looking at this!

        I'm ******* my head against a wall trying to port a well known WPF control library over to UWP. We were cross-platform to Silverlight/WPF so were previously able to implement MultiBinding, DynamicResource and x:Static all as MarkupExtensions. This made our lives much much easier.

        Adding even just a very simplistic version of MarkupExtension to UWP would make the impossible, possible here. Many of the UWP quirks we've worked around but this one really is causing us a headache.

        Do please give us an update as to expected delivery date. I know it's under investigation now but I cannot emphasise enough how much this would mean to us for supporting the platform.

      • Josh McFadden commented  ·   ·  Flag as inappropriate

        >> IServiceProvider, which is a .NET concept that we can't quite solve yet in the UWP platform

        The fact that you struggle to find an implementation for an interface with a SINGLE METHOD deftly underscores everything wrong here with this dysfunctional group.

        >> However WPF, Silverlight and Noises...

        Noises? Perhaps you meant "Noesis." This is a convenient and notable example that demonstrates your group's lack of attention to detail that is apparent in essentially everything you have designed here. Although "Noises" could be a great name for UWP, as it is what you have been feeding us for YEARS now as we have desperately searched for a viable replacement to Silverlight/WPF.

        I am grateful to see that Noesis understands your own technology the way it deserves. I will be taking my team there and suggesting others dump UWP altogether. We are done expending energy on this group's incredible lack of imagination and attention to detail!

      • AdminWindows XAML Team (Admin, Windows Developer) commented  ·   ·  Flag as inappropriate

        Hi @Dustin, thanks for adding votes here. We are currently planning on adding markup extensions support right now with ProvideValue (no service provider though). To answer @Mike's question, spec out means that basically we are defining the implementation for the platform. I can anticipate that someone might say 'duh, it's just the same as what you had before' :-) -- to which I would too! However WPF, Silverlight and Noises operate on the .NET Framework and have different underlying technology that UWP does not have...this is why we are designing the implementation. Our goal here is to support ProvideValue like WPF does with the one exception of IServiceProvider, which is a .NET concept that we can't quite solve yet in the UWP platform (also working on these type of things). If you have further questions, please feel free to email me directly

      • Dustin Mayweather commented  ·   ·  Flag as inappropriate

        It has taken over half a decade to get something that has been available in WPF and Silverlight since the beginning. Markup extensions are also in Noesis, which I have chosen as my rendering system over UWP as the Noesis team not only understands Xaml better than the UWP group, but also do a good job of being very active in their forums and customer base (I see Clint completely ignored Mike's questions and valid points below like a true professional).

        Plus, they are already cross platform and work in iOS and Droid. Yes, markup extensions today that work everywhere. Something UWP hasn't been able to accomplish for years.

      • Andrew Burnett-Thompson commented  ·   ·  Flag as inappropriate

        Very very important for us to port a large WPF control library to UWP. The lack of x:Static would be acceptable if we had MarkupExtension and could write our own. That's what we did for Silverlight.

        The only thing stopping us porting to UWP (our customers are requested UWP) is MarkupExtension. It basically prevents our entire library from working..

      • Mike-EEE commented  ·   ·  Flag as inappropriate

        Well great, thanks for the reply, Clint. I guess I am a little confused on what you mean by "one request per topic." Can you please explain what you mean by this?

        Also, as far as being spec'd out, I guess I am a little confused by this as well. I was under the impression that creating a specification is what determines what goes in and what doesn't. Or rather, describes the features that will make it into this request (or topic?). I would definitely appreciate clarification around this process and what you mean by this.

        To add some more context from my perspective, in the .NET Core/ASP.NET Core/Visual Studio/MSBuild/etc. GitHub repos, the specifications are well-known, descriptive issues that are posted where the community can add their feedback to help drive the direction of those issues so that all (participating :) ) points of view are accounted for and risk is minimized for the final deliverable.

        The obvious concern here is that the first version was conducted in an opaque, closed room manner that resulted in something that developers did not like very much. Doing it again in the same way does not seem like the best course of action to ensure that it will successfully address the requested issues here.

        I am definitely open to feedback here if there is something that I am not understanding.

      • Mike-EEE commented  ·   ·  Flag as inappropriate

        Hi Clint, thinking about this some more after some conversations with a few people. Can you comment on the spec that is occurring with this? There is also a great conversation with the System.Xaml port for .NET Core with lots of feedback for UWP's Xaml model. Well I say feedback, but it's not really all positive and is mostly along the same lines as what birbilis shares below.

        Are the efforts here related in any way to the .NET Core request? Obviously it would be ideal to limit overlap and to leverage work done in one area to solve another (if at all possible).

        Additionally, is there any way to be a part of this process and for the community to provide their own feedback for what is taking place? It would be great to ensure we hit the right notes this time to promote the long-term success/viability of UWP going forward.

        Thank you in advance for any clarity/assistance you can provide here.

      • Mike-EEE commented  ·   ·  Flag as inappropriate

        AWESOME!!! Thank you Clint and team!!! Took a while -- maybe a little TOO long, haha -- but we finally got there. Or are getting there. Sorta like turning the Titanic. :P Looking forward to the progress. :)

      • Dmitry commented  ·   ·  Flag as inappropriate

        Msft srsly? Without custom markup extensions UWP is not a Xaml framework. I have never written an app for UWP and will never write before this suggestion will be implemented. Silverlight is a serious downgrade comparing to WPF, but UWP is about a joke. Facepalm.jpeg here.

      • Titus Rockefeller commented  ·   ·  Flag as inappropriate

        WPF and Silverlight are still better technologies five years after the fact. They don't use these strange, magic string tokens like UWP that sort-of, kind-of masquerade like markup extensions. These markup extensions feel like a team of outsourced, junior developers made them -- basically having absolutely no clue about what .NET is and getting paid to act like it.

        Nope, WPF and Silverlight use real, live markup extensions, the way God intended!!! Also, System.Xaml can be used in all scenarios, not just the under-featured client-tier that UWP has cobbled together. It would be nice to see a separate assembly that can be used outside of clients, but somehow think the outsourced and low-quality culture there won't even consider it.

        Seriously, does anyone over there actually do any work?!?! It's been five years since Silverlight and 1.5 years since this vote was put together!!!

      • Bradley Masterson commented  ·   ·  Flag as inappropriate

        So sad that Microsoft and the Windows group used to be full of smart people who cared and were passionate about the technologies they worked on. Now it is a shell of an organization that simply sits on its hands, waiting for a paycheck. Very disappointing to see that this has taken so long, or really to even identify it as a problem in the first place. Clearly an IQ exodus has taken place.

        Please get your act together and be competitive like you were back in the day. Other Microsoft groups are running circles around you, and far more transparent!

      • Josh McFadden commented  ·   ·  Flag as inappropriate

        Echoing the sentiments here. Why has this taken so long? Xaml system in UWP is a terrible joke and is not even close to older systems. String values are passed back and forth between COM and it is a mess to work with!!! Might as well code it all by hand and ditch the designer altogether. I also too agree with making this open source and cross platform so that all .NET applications can use it for the powerful serialization engine it is, not the UI cluster it has become in UWP, which was clearly written by a team of interns.

        The GitHub vote below says it all. It is overwhelmingly the most popular vote in that repo. LISTEN TO YOUR DEVELOPERS!!!

      Feedback and Knowledge Base