Thanks for the link (and agreement!) @RichiCoder1 … I was hoping for something not UserVoice, preferably. That just seems to be a place where ideas go to die (save maybe two or three per year). I was hoping for maybe a forum to get the ear of the development team somehow. Someplace like this forum (which is really awesome/well-done, btw), but for Universal Apps (which surprisingly/worryingly doesn’t look like is being open-sourced like everything else).

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...

If you could vote for it, it would be much appreciated!

And also, (with all this said), Core.NET needs a UserVoice for assemblies to account for as well.

In any case, I guess none of this really matters until //build, realistically speaking. They either put in markup extensions in Windows 10 or they didn’t. If they did, life is awesome again. However, I do not think anyone is going to announce new features before April 29th. If they didn’t, we still won’t find out until April 29th… so stay tuned until then. I will definitely update this thread then with the latest findings/praise/bitchery.

Three weeks ago, at Mobile World Congress, we had the opportunity to share with you a first look at the Windows 10 universal app platform. Today I’m excited to announce that we are making the first technical preview of the Windows 10 developer...

(in comments)

Pretty sad. It’s my own fault, really. Instead of bitching about it years ago when 8.0 didn’t have it, I should have made that uservoice to give it a shot years later.

So that either means making a System.Xaml on .Net Core 5, or digging into Xamarin.Forms.Xaml, or both. Xamarin seems more agile, so that seems to be the right approach for now. You can also vote for my feature request here:Customer Feedback for Xamarin Platform

After seeing //build2015, I am encouraged by MSFT’s current direction. The two outstanding issues that I see that would make me a happy camper would be better Xaml support (this thread), and open-sourcing/cross-platforming UWP. This might take a couple years, but that would make a perfect MSFT development world again.

I am planning accordingly.

I have already mentioned this, but it bears another mention. It already has 60 votes, which 2nd highest in its category. It would be great to get this into first place and in more visibility with the UWP team. Please take a second or two to make your voice heard and to help create a most ideal MSFT development world (once again).

With the advent of //build 2015, the vision and direction of Microsoft seems to be open source and cross platform. This appears to be the case for every new product from Microsoft except for the Universal Windows Platform.
It would be great,...

Also, off-topic from the original thread, but on-topic with this post (my most ideal MSFT development experience), I also have a vote for the aforementioned open-sourcing/cross-platforming UWP (thereby making it consistent with .NET Core):

With the advent of //build 2015, the vision and direction of Microsoft seems to be open source and cross platform. This appears to be the case for every new product from Microsoft except for the Universal Windows Platform.
It would be great,...

Just a quick mention here. The UWP team is looking at the Xaml vote that I have mentioned above. From reading the conversation in this tweet, there does appear to be a very real disconnect between UWP’s vision/version of Xaml and how WPF/Silverlight5 left it. Specifically, Xaml is “for UI and only UI” in UWP and that simply is not what Xaml is in WPF. Please take a second to share your thoughts on this thread in Twitter and let the UWP team know that you would like to see a System.Xaml equivalent provided in Core.NET that can be used in UWP (and more):

@PauloMorgado - as demonstrated in that Twitter discussion and mentioned in that uservoice vote, Xaml used to be specific to PresentationFramework and WindowsBase, and then got pulled out into its own assembly for generalized use. You can use it to define/serialize POCO objects in addition to UI/presentation objects. You can see frameworks such as MSFT’s Patterns and Practices using it to define their custom objects and serializing/deserializing it from disk/network.

When you add the designer-friendly UI (yes, you get built-in designer support when using Xaml on POCOs!), it becomes in many respects superior to any serialization mechanism out there, especially when you account for markup extensions. The only area in which it is inferior would be its performance, but I feel that would be easily mitigated/addressed in another port.

I have to say it is hard to read what you are trying to say @PauloMorgado … you seem to be supporting my case for a System.Xaml (or Microsoft.Xaml) but then seem to imply that it is only for UI. I’m confused.

I am glad you spell out the definition of Xaml. I have to do that a lot as well. Every letter in the acronym is important, especially X and A. As you know, applications live in a process whose host can be a variable of forms, whether it is a UI process as you suggest, and also a WF process, which can be hosted in IIS or Windows Service, or even a console application. Xaml can be used in any of those scenarios. It can in fact be used in an ASP.NET MVC application (or a WCF application, as I have done) if you so wish. As you state, it is a manner of declaring an object graph in an expressive (and powerful) manner, while also yielding the designer-friendly benefits for which Visual Studio is (maturely) built around for some time now.

So to answer your question, Xaml for WPF is exactly like what Xaml is for WCF, WF, ASP.NET, Console Applications, or any application for that matter: an extensible, serializable, human-readable, designer-friendly, object definition language used to (powerfully) define objects within the scope/domain of an application – wherever that application may reside.

The funny thing here is that if System.Xaml was never made, and Xaml continued to live in PresentationFramework/PresentationCore, we wouldn’t be having this discussion. But, since it was moved out, and made as a great and powerful dependency for all these different technologies (some more used than others), well, then we have a complicated problem, don’t we?

Nice, Curtis! Also a very valid approach. I wonder why no one else thought of that earlier. I also didn’t even realize that Mono had a System.Xaml?! Man… it’s always just one thing after another with software…