Repository navigation
Port System.Xaml to .NET Core #16243
Description
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
- 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).
- 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.
- Prereq for UI frameworks
- ... 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
Activity
Mike-E-angelo commentedon Jan 29, 2016
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 commentedon Jan 29, 2016
@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 commentedon Jan 29, 2016
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 commentedon Jan 29, 2016
@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 commentedon Jan 29, 2016
@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 commentedon Jan 29, 2016
@Michael-DST PCL 259 is indeed compatible with .NET Core, according to this post. I have already included
\lib\dotnetas 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 commentedon Jan 29, 2016
:) 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 commentedon Jan 29, 2016
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 commentedon Jan 30, 2016
@Michael-DST
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 commentedon Jan 30, 2016
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 commentedon Jan 31, 2016
cc: @Harikm86, the owner of System.Xaml
rschiefer commentedon Feb 1, 2016
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 commentedon Feb 1, 2016
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. :) :) :)
135 remaining items
danmoseley commentedon Jun 28, 2018
https://blogs.msdn.microsoft.com/dotnet/2018/05/07/net-core-3-and-support-for-windows-desktop-applications/
lokki commentedon Jul 19, 2018
@danmosemsft will Workflow Foundation xaml be supported in SDK projects as part of 3.0 desktop initiative?
danmoseley commentedon Jul 19, 2018
@lokki I don't know of plans . @terrajobst @karelz?
weitzhandler commentedon Jul 20, 2018
@danmosemsft
Why isn't there an issue that says "Provide a UI framework as part of the .NET Core"?
This issue doesn't talk specifically about the lack of a UI framework, and it doesn't look like the folks here realize that.
See this: microsoft/xaml-standard#232
Silic0nS0ldier commentedon Jul 20, 2018
@weitzhandler This issue makes A LOT more sense to me now. Thanks for the clarification.
I can see having
System.Xamlincluded in the .NET Standard being useful, particularly alongside XAML Standard.birbilis commentedon Jul 20, 2018
if I understand correctly the "desktop initiative", you should be able to use .NET libraries that you could use in the past, as long as you target Windows only (not sure if your app will be able to adapt dynamically to the environment it runs in, if the main app won't be able to do it [e.g. wouldn't launch if it doesn't find say Windows OS] then probably you could do it by making multiple .NET Core assemblies that call the platform specific stuff and load them on demand depending on the platform the app detects it's running on)
weitzhandler commentedon Jul 20, 2018
@birbilis not enough. Same XAML has to render equally in all platforms.
birbilis commentedon Jul 20, 2018
The desktop initiative isn't about XAML, it's about .NET Core not being a least common denominator silo, but instead allow for apps that can target specific platforms (or ideally also dynamically adapt to the platform they're running on) and make the best use out of them, do platform specific integrations etc. One could build capability-based APIs on top of this functionality so that apps can then be written that just query for the availability a specific capability. Also abstracting/compatibility APIs can be build upon that, hooking into different implementations for each platform that the authors of an API are interested in supporting.
cm4ker commentedon Nov 16, 2018
For now, I think, Portable.Xaml is so close to the System.Xaml now. If you find any issue please give feedback.
vatsan-madhavan commentedon Dec 4, 2018
The WPF team (@dotnet/wpf-developers ) has just announced the open-sourcing of WPF for .NET Core 3.0. As part of this, the preview builds for .NET Core 3.0 now contain System.Xaml, and the corresponding sources are available at https://www.github.com/dotnet/wpf.
weitzhandler commentedon Dec 4, 2018
BTW