Nature of Core.NET / System.Xaml


#1

Hello Community,

First post here, so please excuse my newbieness. :slight_smile: I am reading and learning about Core .NET. I am hearing some conflicting explanations around this so I am looking for clarification here.

By some accounts, it sounds like Core .NET is a streamlined version of the .NET Framework, and you can add traditional .NET Framework assemblies into your solution based on need.

Other accounts make it sound like this is a complete overhaul and traditional .NET Framework assemblies will not be compatible at all (or will at the very least require a re-compile of some sort).

The kernel of my questioning/concern has to do around System.Xaml. So, if you can assuage my anxiety here and provide a solution/direction/explanation in the “new” Windows 10 / .NET Core paradigm, I will be most grateful. :smile:

To start with, WinRT implementation of Xaml is an inferior translation of the System.Xaml assembly offering. This is primarily reflected in the fact that markup extensions are not allowed/supported in WinRT. This is truly an unfortunate oversight, as 90% of Xaml’s power (and fun!) lies within these incredible creations.

(For context, markup extensions are provided in WPF, Silverlight 5, and Xamarin.Forms – a non-MSFT technology!, but not WinRT.)

I am basically looking to see/verify if we will be able to use System.Xaml (and other .NET Framework assemblies) with Core .NET, or if this expected to be unsupported.

Secondly, if System.Xaml is not available for/compatible with Core .NET, it would be great to know:

  1. How difficult it would be to port System.Xaml over to the new Core .NET (as an open-source project, perhaps).
  2. (Trickier to answer here as this is out of the scope of Core .NET) If markup extensions are accounted for, corrected, and supported in the new Xaml offerings for Windows 10 App Model (I have a feeling I will just have to be patient and wait for //build for this answer :innocent:).

Thank you for any assistance/clarification/insight.
Michael


WCF 5 for .NET Core 5
#2

System.Xaml doesn’t seem to be listed in the list of APIs planned to be moved to .Net Core.


#3

Thanks for your reply @svick … I did see that list, and I am not sure what this means, which is why I am asking it here. :smile: Will System.Xaml be completely incompatible with the new Core .NET? And if so, what are our options?

Xaml is so ubiquitous in the MSFT ecosystem that this is pretty surprising. But at least XML made it. :stuck_out_tongue:


#4

Yes, traditional .NET assemblies aren’t compatible with the Core subset, they need to be recompiled (and modified where functionality/APIs aren’t there anymore).

See also this great GitHub thread for more information: https://github.com/dotnet/corefx/issues/973


#5

That IS a pretty incredible thread, @akoeplinger. Thank you for the reference. I am feeling better about understanding how .NET Core works now and my concerns have been validated as a result of it, unfortunately.

Again, this is pretty unfortunate and disheartening direction. Much effort was put into taking Xaml serialization out of the presentation assemblies and making them generally available for general purpose use regardless of where an application is running. Now it appears we are at the mercy of the Xaml serialization mechanism that is defined with the Windows 10 app model, which not only isolates where the Xaml serialization assemblies are located but places them them once again within the client boundary (when, again, a lot of effort was made to take them OUT of the client boundary).

If there ends up being a Windows.Xaml assembly in the Windows 10 app model, (and it happens to finally utilize markup extensions) that can be used outside of client applications then hallelujah(!!!) happy coding days are here again and we can finally start developing some serious applications. Otherwise, I guess I will be pinging this thread after //build to determine next depressing steps to resurrect a cherished, powerful, and ubiquitously useful library that met an unnecessarily cruel and sudden end. :disappointed:

Bring on //build, then. I almost feel like Lando Calrissian here… “Come on Microsoft ol’ buddy… don’t let me down.” :stuck_out_tongue_winking_eye:


#6

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!


#7

For WinPlat dev, the Windows Dev Platform user voice would be a good place to voice your concern and request additions:
https://wpdev.uservoice.com/forums/110705-dev-platform

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.


#8

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

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


#9

Well it has been confirmed that Windows 10 will not support markup extensions:

(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:


#10

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

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). :smile:

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.


#11

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!


#12

What is XAML for in WPF other than UI? What is WPF other than UI?


#13

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


#14

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?


#15

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

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.


#16

You wrote:

And I questioned:


#17

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?


#18

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.


#19

Xaml for WCF .NET Core configuration? It could happen. :smile:
http://forums.dotnetfoundation.org/t/wcf-5-for-net-core-5/1223/6


Cross platform WPF
#20

Nevermind. #problemsolved. :wink:


.NET Foundation Website | Blog | Projects | Code of Conduct