Port System.Xaml to .NET Core

[terrajobst]

Filed as a result of the discussion in #14862.

Note: this doesn't represent a commitment from us to open source System.Xaml or to even port it to .NET Core -- it's simply capturing the community request to do so.

---

Scenarios

1. WF (Workflow Foundation) - Port Workflow Foundation to .NET Core #14862
   • However, note that CoreWF is also trying to abstract serialization from Xaml (as it was originally intended). That said, all existing Desktop serialziations are in Xaml and we need it for transition path at minimum (having converters would be another option).
2. Prereq for WPF
   • Note: WPF / GUI frameworks are a big step for .NET Core (which targets server and console apps scenarios today) - it needs full end-to-end plan & commitment first.
3. Prereq for UI frameworks
   • https://github.com/AvaloniaUI/Avalonia - @grokys (see https://github.com/dotnet/corefx/issues/5766#issuecomment-275260663)
   • Eto.Forms - @cwensley (see https://github.com/dotnet/corefx/issues/5766#issuecomment-275282292)
4. ... more scenarios will be added based on the discussion
   • @mike-eee's devops scenario - waiting on more details
   • @Kation's non-UI framework scenarios - waiting on more details

[Mike-E-angelo]

HORRAY! Official recognition/acknowledgement! And yes, I realize that those words do NOT equate to "commitment" but this is definitely better than anything that I have seen so far. @terrajobst you are my hero. ❤️ ❤️ ❤️

[Mike-E-angelo]

@cwensley and @SuperJMN, it would be great to get some dialogue between everyone here. Ideally (from my perspective) everyone should ultimately use one port/version of the new Xaml library and not have different versions/dialects of Xaml out there. Is this even remotely possible? I'm OK with it if not, but I would like to see if we can if so. :)

Also, I am currently on a "working sabbatical (from bossy clients LOL)" and I have 3-4 months slated to cross-platform Xaml alone. I could literally work full time and help out on this during that time if necessary. Anything for the cause (and also, I'm an opportunist for good timing!)

[shahid-pk]

if System.Xaml got open source i am sure the community can port it to .net core according to this project's requirement and design goals, the project maintainers will only need to guide the community. Lets leverage the power of .net community.

[cwensley]

@Michael-DST, I agree having one dialect of xaml is important. However, the implementation of that might be entirely different. Standardizing on a single implementation depends on the community really.

For Portable.Xaml which is a PCL 259/136 port of Mono's excellent System.Xaml (MIT licensed) implementation, with many bugfixes. The idea is to support everything that MS' System.Xaml does (including reading/writing) using the same API, but not necessarily be limited to it.

As an example of extended functionality, Portable.Xaml supports using type converters on items in a list, where System.Xaml uses IList.Add(object) which you'd have to implement using a custom collection to support various types.

[Mike-E-angelo]

@cwensley I claim my ignorance on this... but what is the difference between .NET Core and PCL? I thought they were the same? That is, it was my understanding that if you designed under a certain PCL profile, that it would carry over to .NET Core... this was a while ago (and honestly I was waiting for .NET Core to RTM/W), so now is a good time to refresh. :P

It is my understanding/impression that Portable.Xaml is indeed a port of mono's System.Xaml, while OmniXaml is a rewrite from the ground up that features some new hotness in the parsing arena. Ideally (from my own perspective) it would be great to merge the two somehow, but I am not even sure that is feasible, or even desirable between the two bases. In my mind (without doing the spelunking/analysis) it is basically merging the maturity of the one (Portable.Xaml) with the new hotness of the other (OmniXaml).

[cwensley]

@Michael-DST PCL 259 is indeed compatible with .NET Core, according to this post. I have already included \lib\dotnet as a target in the nuget package for Portable.Xaml, so it should be usable as-is for .NET Core, though I have not tested it.

I haven't had the time to look into OmniXaml, but if it is indeed a rewrite from the ground up it may not make sense to merge the two projects as I'm sure things would have been done completely different. I'm also not sure of the benefit of such a thing if Portable.Xaml is mostly complete as is. I could be wrong though (;

[Mike-E-angelo]

:) Yes, I am exploring options here, and also dealing with my ignorance with really being in an open source world. I do hate the idea of having multiple codebases out there doing the same thing. And especially with the Xaml community being smaller, it would suck having it get fragmented right out of the get-go (isn't that supposed to happen after something gets too successful for its own good?! haha). Anyways, it would be great to hear @SuperJMN's take on this. I know he seemed pretty firm on his new modifications. For instance, the use of MarkupExtensionContext in place of IServiceProvider for markup extensions, which would be a breaking change for anyone wanting to port existing code over to this new world.

[mellinoe]

To clarify, all PCL profiles are compatible with .NET Core. The contract sets and factorings we have now are an evolution of PCL profiles. This doesn't apply to "old-style" portable libraries (compiled against mscorlib, etc.) which aren't immediately compatible with .NET Core.

[terrajobst]

@Michael-DST

@terrajobst you are my hero. ❤️ ❤️ ❤️

While I highly appreciate your enthusiasm I want to make it clear that anybody can file requests like this. You don't need any sponsorship or acknowledgement from us in order to file issues, asking for work :-) I merely filed it myself to save some time and not be super lame ("feel free to file a bug") :-)

[Mike-E-angelo]

LOL @terrajobst it is OK, my enthusiasm is half tongue-in-cheek and half-serious... MSFT has been basically silent on this issue for nearly a year now, despite numerous votes and extensive conversations.

So, consider what you did the equivalent of sliding a meal under the door of someone locked in solitary confinement for nearly a year. 😛

[Edit: after reading that analogy (and seeing it quoted below), I have to say it's terrible and probably influenced by an article that I was reading at the time -- damn you news, why must you influence me so?! A better/relevant one would probably be getting a much needed injection of cash from an angel round after a year of running on fumes.]

[zhenlan]

cc: @Harikm86, the owner of System.Xaml

[rschiefer]

I love XAML. Its a great declarative language for everything from Silverlight (yes, I said it) to Windows Workflow and now to the new Universal App platform. Porting to Core will make it possible to port other technologies that depend on XAML. We need this!

[Mike-E-angelo]

Great to hear your support @rschiefer! Thank you for your input. Please make sure you have other Xaml developers that you know of join this thread and help out with the conversation/direction.

I am also a fan of Silverlight and have been chasing after its next incarnation since 2011 (shameless plug: if you would like to let Visual Studio team know you'd like to see the next, smarter form of Silverlight, please vote and let them know here).

I would like to take a second and make sure that when we say "Xaml" we should aspire for the Xaml system/feature set found in .NET 4.x+ (or "System.Xaml"). Even Silverlight 5's Xaml will do, really.

(Of course, adding in the new improvements found in OmniXaml is desired, as well.)

As long as it is not the "new", bastardized version in UWP that must have been ported over by a team of interns, as we all have been suffering from it since (see the votes that I mention in my post above).

I really even hesitate to call that a "Xaml" system, as it is really XML with some extra token parsing for good luck (which it clearly needs). Fun fact: UWP's Xaml system ultimately uses the System.Xaml assembly during its build process. Mmm... #irony.

Ideally once this port is in place, the UWP Xaml system will be deprecated altogether and use this one instead. We can then put that chapter of embarrassing Xaml history behind us, and much developer rejoicing will be had.

Getting Silverlight back in a newer, better form wouldn't be bad, either. :) :) :)