Port System.Xaml to .NET Core #16243
Comments
|
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. ❤️ ❤️ ❤️ |
|
@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!) |
|
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. |
|
@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. |
|
@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). |
|
@Michael-DST PCL 259 is indeed compatible with .NET Core, according to this post. I have already included 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 (; |
|
:) 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. |
|
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. |
|
@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") :-) |
|
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.] |
|
cc: @Harikm86, the owner of System.Xaml |
|
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! |
|
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. :) :) :) |
|
@Michael-DST
Fair enough 😄 |
|
@Michael-DST I have actually avoided UWP up to this point knowing a lot had changed and I had forgotten UWP used its own "version" of Xaml. Thanks for reminding me. I completely agree, System.Xaml should be ported and then we can fix UWP to use real Xaml. |
Sorry @terrajobst, I have a new hero now in @rschiefer. 😄 😄 😄 Thank you all for the discussion. This is super cool to me (but I could just be easily impressed!). |
|
@Michael-DST @rschiefer |
|
@helmsb YES! LOL haha! |
|
FWIW, the competitive Google's popular Material Design tech for web (Angular.js), apps (Android) etc. is also available open source. Hope this argument help convincing the bosses and boss-like entities. |
|
@dsaf what you mean? |
|
FWIW I have referenced this issue in an article posted today titled Is the Tide Turning on project.json?, a look at how Xaml is a preferred mechanism for describing .NET objects from both a technical and MSFT business/IP perspective. |
|
Well everyone, how about that Xamarin deal, huh! something tells me that this issue is going to get a lot busier in the coming months. 😄 |
|
Not necessarily. There might be a good chance what we see UWP's Xaml or Xamarin's flavor of Xaml become some cross platform library. Which might mean neither a port of System.Xaml or even a purely managed Xaml implementation may happen. |
|
Xamarin's Xaml system is closed/internal though and nowhere near as mature as System.Xaml. The code itself is rather flimsy (an acknowledged concern on their end -- actually using that is one of the reasons it is closed/internal). Additionally, it is tightly-coupled to BindingObject which is prohibitive if you are wanting to do POCO serialization, etc. And as outlined above, UWP's Xaml system is t-e-r-r-i-b-l-e. Unless there is something that you know that I do not know about. 😛 Can you explain what you mean by "purely managed Xaml implementation"? FWIW, my expectation here isn't exactly a direct 1:1 port of System.Xaml but a "new" System.Xaml (Microsoft.Xaml?) library that takes all the goodness from System.Xaml, Xamarin.Core.Xaml, and ... well, I would say UWP's Xaml, but... 😉 |
|
I've heard that internally there's a preference for UWP's Xaml over WPF and such's Xaml, though obviously different teams at Microsoft may have different opinions. DotNet's Xaml is without a doubt more powerful and flexible, but as with anything with those descriptors that likely comes with drawbacks that are the reason UWP is so scaled back. |
|
Alright, I am confused. When you say .NET... you're talking 4.6, right? From my understanding this is for a .NET Core Xaml library, which by its very nature is cross-platform and .NET (4.6) exclusive? When you say "not DotNet exclusive" you mean "is DotNet inclusive"? Double-negatives. 😛 This is obviously not true because you cannot use UWP Xaml in .NET 4.6 (nor would you want to 😛). Please enlighten me on what I have wrong here. Additionally, a good goal here would be to get Xaml shipped as part of CoreFX. Some discussion has been going around this for some time. -- and sure enough, if I am not mistaken @RichiCoder1 you have your vote to do exactly this in that thread... I was wondering where I have seen your tag before! 😄 |
|
And I would also like to say that I have also heard the internal leanings towards UWP's Xaml, but that was before there was some community discussion around it starting in that thread above and beyond (ala Tim Heuer's Twitter discussion). The needle has definitely moved since then. At least, it had better! LOL. There are those with the misconception that "Xaml is for UI" and then there is the rest of us that understand how it works. 😛 |
|
My dream is using android xml ui writings style for desktop apps with dot net core! yes, really!! |
|
Any effort to port XAML to .NET core I am willing to volunteer. |
|
In my modifications to CoreWf (WorkflowFoundation on net standard 2.0), I see that System.Xaml or a more compatible Portable.Xaml implementation will probably be required to allow DynamicActivity loading from Xaml. I have CoreWf running on .net framework with basic DynamicActivity loading using System.Xaml, but still failing due to invalid parsing state on .net core with Portable.Xaml. One question is why is the code to System.Xaml not added to the Mit licensed reference source repo? Is there a licensing, patent or other issue? If there is no issue, adding this code to reference source would allow us, the community, to do the porting necessary to support CoreWf. The Reference source repo does not commit Microsoft to support the System.Xaml. Should I add an issue there asking for System.Xaml to be opened? If System.Xaml is not opened, then can we have a document (other then the Xaml spec) or support in the form of tests that describe the correct steps to parsing and tokenizing the Xaml code for WorkflowFoundation? |
|
Hey FWIW @karelz I've put some thoughts into the DevOps scenario here: Based on some cool happenings in the Visual Studio Xaml Designer: Thought I would mention it here, while I was at it. 👍 Besides, this thread is overdue for a bump. 😆 |
|
@weitzhandler u need to be updated, as mono-wasm is on the alpha way, it is almost time to start forget js. |
|
@weitzhandler 2 or 3 years r required, but it is not just a full-stack, it is a universal-stack for .net. |
|
CoreRT is also on board- dotnet/corert#4480 . Hoping for a production ready HTML+CSS+C# combo next year. |
|
Proposed .net compatibility pack includes |
|
Apparently this issue has been linked for the compat pack 2.1? Can someone confirm? I see that it has been tagged netfx-compat-pack, but not with a version. I'll take that over anything that has occurred thus far, though. 😄 |
|
Hate to disappoint but I think I accidentally marked this as 2.1 when I was bulk updating the issues of the comapt pack. I've moved to Future to reflect the maybe status in the proposal. |
|
@Mike-EEE it seems that xamarin.wasm is to arrive. |
|
Thanks for the update gents. Appreciate you thinking of me. :) @terrajobst that is indeed disappointing, but I appreciate you taking the time to check in and update. I wasn't sure if you were still subscribed to this thread anymore or not. 👼 Since we're taking time to shamelessly plug projects (and that it will be some time before we get our official Xaml fix), I will take a second to mention that I've been spending the past year helping out with v2 of ExtendedXmlSerializer, which was recently released. It features experimental support for markup extensions and attached properties (that work on POCO, no If you are looking for (or to add) Xaml-ish functionality while we're waiting for System.Xaml to arrive, then feel free to check it out, provide feedback, or (better yet) submit a PR in the repo. 👍 |
|
@danmosemsft will Workflow Foundation xaml be supported in SDK projects as part of 3.0 desktop initiative? |
|
@lokki I don't know of plans . @terrajobst @karelz? |
|
@danmosemsft This issue doesn't talk specifically about the lack of a UI framework, and it doesn't look like the folks here realize that. |
|
@weitzhandler This issue makes A LOT more sense to me now. Thanks for the clarification. I can see having |
|
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) |
|
@birbilis not enough. Same XAML has to render equally in all platforms. |
|
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. |
|
For now, I think, Portable.Xaml is so close to the System.Xaml now. If you find any issue please give feedback. |
|
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. |
ghost
locked as resolved and limited conversation to collaborators
and others
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
The text was updated successfully, but these errors were encountered: