Also, if someone happens to know the best forum to direct my ask/concerns for markup extensions in the new Windows 10 app model, that would be very helpful. Thanks in advance!
For WinPlat dev, the Windows Dev Platform user voice would be a good place to voice your concern and request additions:
I’d like to also echo here my agreement elsewhere that System.Xaml should be added to .Net Core, even if only to read and process Xaml files.
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).
Nonetheless, I did create a vote there to get something started in case it was not picked up by the new Windows 10 tech:
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.
Well it has been confirmed that Windows 10 will not support markup extensions:
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:
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).
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):
Thank you for any consideration and interest.
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):
Thank you for any consideration and support!
What is XAML for in WPF other than UI? What is WPF other than UI?
@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.
XAML stands for eXtensible Application Markup Language, regardless of how badly packaged it was/is. It’s used in WPF to describe the objects that make up the UI.
XAML was also used by WF, although it was called XOML (O for Orchestration).
So, what is XAML for in WPF other than UI? And, what is WPF other than UI?
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?
Please let me know if I misread your comment/question.
And I questioned:
I believe and feel I answered your questions, albeit not as succinctly as asked. Can you tell me what part about my answer to your questions is not sufficient, incorrect, and/or you do not understand?
After re-reading my comment above in full context @PauloMorgado, I see what you are saying now. I should have said:
“…and that simply is not what Xaml is in WPF and .NET.”
Thank you for pointing that out.
Xaml for WCF .NET Core configuration? It could happen.
Cross platform WPF
I’ve now done just that and created Portable.Xaml, with fresh nugets. I’ve ported it so far to PCL 259 (which supports CoreCLR) and PCL 136 (for .NET 4.0 support).
Needs a little work on the TypeConverters for basic types, but other than that it is very usable!
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…
FWIW, another vote on the Visual Studio boards is erupting after 2 days, just to drive home the point:
Nearly a year later and we finally have official recognition (note, not commitment – yet) from MSFT towards this: