New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Port System.Xaml to .NET Core #5766

Open
terrajobst opened this Issue Jan 29, 2016 · 155 comments

Comments

Projects
None yet
@terrajobst
Member

terrajobst commented Jan 29, 2016

Filed as a result of the discussion in #2394.

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) - #2394
    • 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
  4. ... more scenarios will be added based on the discussion
@Mike-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE 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-EEE commented 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-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE 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!)

Mike-EEE commented 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

This comment has been minimized.

Show comment
Hide comment
@shahid-pk

shahid-pk 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.

shahid-pk commented 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

This comment has been minimized.

Show comment
Hide comment
@cwensley

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

cwensley commented 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-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE 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).

Mike-EEE commented 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

This comment has been minimized.

Show comment
Hide comment
@cwensley

cwensley Jan 29, 2016

@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 (;

cwensley commented Jan 29, 2016

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

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE 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.

Mike-EEE commented 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

This comment has been minimized.

Show comment
Hide comment
@mellinoe

mellinoe Jan 29, 2016

Contributor

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.

Contributor

mellinoe commented 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

This comment has been minimized.

Show comment
Hide comment
@terrajobst

terrajobst Jan 30, 2016

Member

@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") :-)

Member

terrajobst commented Jan 30, 2016

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

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE 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.]

Mike-EEE commented 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

This comment has been minimized.

Show comment
Hide comment
@zhenlan

zhenlan Jan 31, 2016

Member

cc: @Harikm86, the owner of System.Xaml

Member

zhenlan commented Jan 31, 2016

cc: @Harikm86, the owner of System.Xaml

@zhenlan zhenlan removed their assignment Jan 31, 2016

@rschiefer

This comment has been minimized.

Show comment
Hide comment
@rschiefer

rschiefer 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!

rschiefer commented 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-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE 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. :) :) :)

Mike-EEE commented 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. :) :) :)

@terrajobst

This comment has been minimized.

Show comment
Hide comment
@terrajobst

terrajobst Feb 1, 2016

Member

@Michael-DST

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

Fair enough 😄

Member

terrajobst commented Feb 1, 2016

@Michael-DST

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

Fair enough 😄

@rschiefer

This comment has been minimized.

Show comment
Hide comment
@rschiefer

rschiefer Feb 1, 2016

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

rschiefer commented Feb 1, 2016

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

@Mike-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE Feb 1, 2016

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!).

Mike-EEE commented Feb 1, 2016

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!).

@helmsb

This comment has been minimized.

Show comment
Hide comment
@helmsb

helmsb commented Feb 1, 2016

@Michael-DST @rschiefer
_84538408_7751d5e5-fce7-42fd-b90d-fe31e6c71421_020116_014028_pm

@Mike-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE Feb 1, 2016

@helmsb YES! LOL haha!

Mike-EEE commented Feb 1, 2016

@helmsb YES! LOL haha!

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Feb 2, 2016

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.

ghost commented Feb 2, 2016

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.

@galvesribeiro

This comment has been minimized.

Show comment
Hide comment
@galvesribeiro

galvesribeiro Feb 2, 2016

Member

@dsaf what you mean?

Member

galvesribeiro commented Feb 2, 2016

@dsaf what you mean?

@Mike-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE Feb 11, 2016

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.

Mike-EEE commented Feb 11, 2016

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.

@Mike-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE Feb 25, 2016

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

Mike-EEE commented Feb 25, 2016

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

@RichiCoder1

This comment has been minimized.

Show comment
Hide comment
@RichiCoder1

RichiCoder1 Feb 25, 2016

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.

RichiCoder1 commented Feb 25, 2016

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.

@Mike-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE Feb 25, 2016

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

Mike-EEE commented Feb 25, 2016

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

@RichiCoder1

This comment has been minimized.

Show comment
Hide comment
@RichiCoder1

RichiCoder1 Feb 25, 2016

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.
And by non purely managed, I'm refering to the one nice thing about UWP's Xaml in that it's not DotNet exclusive. So a potential future Microsoft.Xaml could be a cross-plat native implementation with a managed facade so it could be used outside DotNet. (That would also exclude it's inclusion in dotnet/corefx unless this future library was decided to ship as a component of CoreFX)

RichiCoder1 commented Feb 25, 2016

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.
And by non purely managed, I'm refering to the one nice thing about UWP's Xaml in that it's not DotNet exclusive. So a potential future Microsoft.Xaml could be a cross-plat native implementation with a managed facade so it could be used outside DotNet. (That would also exclude it's inclusion in dotnet/corefx unless this future library was decided to ship as a component of CoreFX)

@Mike-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE Feb 25, 2016

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! 😄

Mike-EEE commented Feb 25, 2016

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! 😄

@Mike-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE Feb 25, 2016

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

Mike-EEE commented Feb 25, 2016

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

@RichiCoder1

This comment has been minimized.

Show comment
Hide comment
@RichiCoder1

RichiCoder1 Feb 25, 2016

When I say DotNet, I mean DotNet including core and framework. And I realize you can't use UWP Xaml outside UWP apps, I was referring to the ability to use it in C++ UWP apps. So when I say not having it be DotNet exclusive, I mean being about to use it from C++ (or potentially other languages). And I imagine the reason why the team that owns XAML doesn't consider use cases outside UI seriously is because it's either uncommon or, in some cases, actively maligned with Microsoft or with partners. Not my personal opinion, I appreciate it's expressiveness and power.

RichiCoder1 commented Feb 25, 2016

When I say DotNet, I mean DotNet including core and framework. And I realize you can't use UWP Xaml outside UWP apps, I was referring to the ability to use it in C++ UWP apps. So when I say not having it be DotNet exclusive, I mean being about to use it from C++ (or potentially other languages). And I imagine the reason why the team that owns XAML doesn't consider use cases outside UI seriously is because it's either uncommon or, in some cases, actively maligned with Microsoft or with partners. Not my personal opinion, I appreciate it's expressiveness and power.

@Mike-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE Feb 25, 2016

OK great @RichiCoder1 thank you for your explanation. I think I almost completely follow you now... when you say "framework" you mean 4.6?

In my view, I will say that part of the reason why the internal team feels that it's uncommon to use it outside of UI has to do with poor engagement with developers, as I think Tim's post shows. I am also guilty of this as I really didn't get chirpy about engaging MSFT until about a year or so ago? In fact Tim's Tweet was about a vote that I had made, after I had been personally/privately complaining to everyone since Windows 8.0 that the Xaml system was completely different and unlike what it should be. When I heard rumblings that UWP (Windows 10) Xaml was basically the same -- after 3 years of no innovation or improvement -- that's when I stepped up. In hindsight it should have been much sooner.

Safe to say that was a major learning lesson. I am (or at least feel like I am) now much more integrated in the ecosystem and feel like I am being heard. In fact, a very important vote I made a little over four months ago was marked as Under Review by the prestigious Visual Studio team earlier this week. To say my world has been rocked is an understatement. 😄

Mike-EEE commented Feb 25, 2016

OK great @RichiCoder1 thank you for your explanation. I think I almost completely follow you now... when you say "framework" you mean 4.6?

In my view, I will say that part of the reason why the internal team feels that it's uncommon to use it outside of UI has to do with poor engagement with developers, as I think Tim's post shows. I am also guilty of this as I really didn't get chirpy about engaging MSFT until about a year or so ago? In fact Tim's Tweet was about a vote that I had made, after I had been personally/privately complaining to everyone since Windows 8.0 that the Xaml system was completely different and unlike what it should be. When I heard rumblings that UWP (Windows 10) Xaml was basically the same -- after 3 years of no innovation or improvement -- that's when I stepped up. In hindsight it should have been much sooner.

Safe to say that was a major learning lesson. I am (or at least feel like I am) now much more integrated in the ecosystem and feel like I am being heard. In fact, a very important vote I made a little over four months ago was marked as Under Review by the prestigious Visual Studio team earlier this week. To say my world has been rocked is an understatement. 😄

@RichiCoder1

This comment has been minimized.

Show comment
Hide comment
@RichiCoder1

RichiCoder1 Feb 25, 2016

By framework, I'm using it to refer to desktop .Net. That seems to be the popular way to differentiate between Core and the Full Framework.

I agree. One of the nice things about all of Microsoft recents moves is it almost forces better engagement with developers :).

Very excited about that myself! Now just to see how that plays would. That could mean anything from making the Xamarin tooling first class aside UWP apps using their shared projects, or it could mean something high level then even that. Only time (and I guess, //Build) will tell.

RichiCoder1 commented Feb 25, 2016

By framework, I'm using it to refer to desktop .Net. That seems to be the popular way to differentiate between Core and the Full Framework.

I agree. One of the nice things about all of Microsoft recents moves is it almost forces better engagement with developers :).

Very excited about that myself! Now just to see how that plays would. That could mean anything from making the Xamarin tooling first class aside UWP apps using their shared projects, or it could mean something high level then even that. Only time (and I guess, //Build) will tell.

@Mike-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE Feb 25, 2016

OK cool... thank you for the info. 👍

As for //build... indeed. :) Personally, I would like to see a new model altogether that is (loosely?) based on UWP and utilize the new Xamarin goodness to move it to iOS/Droid. Stronger Xaml model wouldn't hurt, either. Guess we should keep this thread quiet until after April 28th, after all. 😛

Mike-EEE commented Feb 25, 2016

OK cool... thank you for the info. 👍

As for //build... indeed. :) Personally, I would like to see a new model altogether that is (loosely?) based on UWP and utilize the new Xamarin goodness to move it to iOS/Droid. Stronger Xaml model wouldn't hurt, either. Guess we should keep this thread quiet until after April 28th, after all. 😛

@maxima120

This comment has been minimized.

Show comment
Hide comment
@maxima120

maxima120 Feb 27, 2016

I hope you guys can do it ! :)

maxima120 commented Feb 27, 2016

I hope you guys can do it ! :)

@birbilis

This comment has been minimized.

Show comment
Hide comment
@birbilis

birbilis Mar 11, 2016

Guess the UWP guys would more easily adopt a XAML implementation that doesn't pull-in .NET code (even if that code was .NET Core stuff).

Like a self-contained black box (or only depending on UWP, but we don't want that since UWP is non-crossplatform [yet] and if it was one would still miss a managed version of it that could run in .NET/Silverlight [can't lock your apps to just Win10 target]).

But this is more or less utopic I think, unless you make it with an abstraction layer and pluggables / drivers for the different applications of XAML (for UWP UI, for Workflow, for WPF/.NET, for Silverlight etc.). Like how DirectX seems a machine via HAL (Hardware Abstraction Layer), which also opens the possibility for HEL (Hardware Emulation Layer - see mentions at http://www.developer.com/net/asp/article.php/968461/What-is-DirectX.htm). Of course if you're not careful it could also open the door to hell regarding performance, but since DirectX could pull it, I guess such architecture isn't bad

birbilis commented Mar 11, 2016

Guess the UWP guys would more easily adopt a XAML implementation that doesn't pull-in .NET code (even if that code was .NET Core stuff).

Like a self-contained black box (or only depending on UWP, but we don't want that since UWP is non-crossplatform [yet] and if it was one would still miss a managed version of it that could run in .NET/Silverlight [can't lock your apps to just Win10 target]).

But this is more or less utopic I think, unless you make it with an abstraction layer and pluggables / drivers for the different applications of XAML (for UWP UI, for Workflow, for WPF/.NET, for Silverlight etc.). Like how DirectX seems a machine via HAL (Hardware Abstraction Layer), which also opens the possibility for HEL (Hardware Emulation Layer - see mentions at http://www.developer.com/net/asp/article.php/968461/What-is-DirectX.htm). Of course if you're not careful it could also open the door to hell regarding performance, but since DirectX could pull it, I guess such architecture isn't bad

@juepiezhongren

This comment has been minimized.

Show comment
Hide comment

juepiezhongren commented May 16, 2017

@Mike-EEE @terrajobst @terrajobst @cwensley @mellinoe
I have created a issue in Xaml Standard.
Microsoft/xaml-standard#57

@Mike-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE May 16, 2017

Thanks for the heads up and contributing to the conversation, @juepiezhongren!

Mike-EEE commented May 16, 2017

Thanks for the heads up and contributing to the conversation, @juepiezhongren!

@Mike-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE May 21, 2017

well @lokitoth I'm glad we kept this issue intact as it was decided Microsoft/xaml-standard#23 was not fit for daylight.

I have, however, created a new issue that I feel does a better job describing the issue at hand and it would be awesome to have your upvote and/or contributions added here: Microsoft/xaml-standard#145

Mike-EEE commented May 21, 2017

well @lokitoth I'm glad we kept this issue intact as it was decided Microsoft/xaml-standard#23 was not fit for daylight.

I have, however, created a new issue that I feel does a better job describing the issue at hand and it would be awesome to have your upvote and/or contributions added here: Microsoft/xaml-standard#145

@Mike-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE May 29, 2017

To clarify, what you are looking for would actually be JavaScript+HTML5+CSS3 generated artifacts. TypeScript is actually a transpiler for JS. Instead of making a .NET transpiler to produce standards-compliant JS that would effectively execute in a browse (like JSIL), MSFT decided to spend the precious time of C#'s creator to make something that would effectively and ultimately compete with it.

I would say don't get me started on this, but I don't think I ever stopped. 😛

Also, another point is that CSHTML5 is very close to what you are looking for @weitzhandler, but it doesn't allow for shared code between client/server assemblies (like PCLs, etc). So you still end up with two separate, incompatible code bases to maintain, resulting in the same cost/business problem between .NET and JS (or TypeScript 😉) that, say, doesn't exist in a strictly NodeJS solution.

Mike-EEE commented May 29, 2017

To clarify, what you are looking for would actually be JavaScript+HTML5+CSS3 generated artifacts. TypeScript is actually a transpiler for JS. Instead of making a .NET transpiler to produce standards-compliant JS that would effectively execute in a browse (like JSIL), MSFT decided to spend the precious time of C#'s creator to make something that would effectively and ultimately compete with it.

I would say don't get me started on this, but I don't think I ever stopped. 😛

Also, another point is that CSHTML5 is very close to what you are looking for @weitzhandler, but it doesn't allow for shared code between client/server assemblies (like PCLs, etc). So you still end up with two separate, incompatible code bases to maintain, resulting in the same cost/business problem between .NET and JS (or TypeScript 😉) that, say, doesn't exist in a strictly NodeJS solution.

@mehdico

This comment has been minimized.

Show comment
Hide comment
@mehdico

mehdico Jun 10, 2017

My dream is using android xml ui writings style for desktop apps with dot net core! yes, really!!

mehdico commented Jun 10, 2017

My dream is using android xml ui writings style for desktop apps with dot net core! yes, really!!

@giorgiozoppi

This comment has been minimized.

Show comment
Hide comment
@giorgiozoppi

giorgiozoppi Jun 23, 2017

Any effort to port XAML to .NET core I am willing to volunteer.

giorgiozoppi commented Jun 23, 2017

Any effort to port XAML to .NET core I am willing to volunteer.

@ewinnington

This comment has been minimized.

Show comment
Hide comment
@ewinnington

ewinnington Aug 7, 2017

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?

ewinnington commented Aug 7, 2017

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?

@Mike-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE Sep 13, 2017

Hey FWIW @karelz I've put some thoughts into the DevOps scenario here:
https://visualstudio.uservoice.com/forums/121579-visual-studio-ide/suggestions/31381861-innovate-the-xaml-designer-dawg

Based on some cool happenings in the Visual Studio Xaml Designer:
https://blogs.msdn.microsoft.com/visualstudio/2017/09/11/a-significant-update-to-the-xaml-designer/

Thought I would mention it here, while I was at it. 👍 Besides, this thread is overdue for a bump. 😆

Mike-EEE commented Sep 13, 2017

Hey FWIW @karelz I've put some thoughts into the DevOps scenario here:
https://visualstudio.uservoice.com/forums/121579-visual-studio-ide/suggestions/31381861-innovate-the-xaml-designer-dawg

Based on some cool happenings in the Visual Studio Xaml Designer:
https://blogs.msdn.microsoft.com/visualstudio/2017/09/11/a-significant-update-to-the-xaml-designer/

Thought I would mention it here, while I was at it. 👍 Besides, this thread is overdue for a bump. 😆

@juepiezhongren

This comment has been minimized.

Show comment
Hide comment
@juepiezhongren

juepiezhongren Sep 15, 2017

@weitzhandler u need to be updated, as mono-wasm is on the alpha way, it is almost time to start forget js.

juepiezhongren commented Sep 15, 2017

@weitzhandler u need to be updated, as mono-wasm is on the alpha way, it is almost time to start forget js.

@juepiezhongren

This comment has been minimized.

Show comment
Hide comment
@juepiezhongren

juepiezhongren Sep 15, 2017

@weitzhandler 2 or 3 years r required, but it is not just a full-stack, it is a universal-stack for .net.

juepiezhongren commented Sep 15, 2017

@weitzhandler 2 or 3 years r required, but it is not just a full-stack, it is a universal-stack for .net.

@gulshan

This comment has been minimized.

Show comment
Hide comment
@gulshan

gulshan Sep 15, 2017

CoreRT is also on board- dotnet/corert#4480 . Hoping for a production ready HTML+CSS+C# combo next year.

gulshan commented Sep 15, 2017

CoreRT is also on board- dotnet/corert#4480 . Hoping for a production ready HTML+CSS+C# combo next year.

@gulshan

This comment has been minimized.

Show comment
Hide comment
@gulshan

gulshan Oct 26, 2017

Proposed .net compatibility pack includes System.Xaml with maybe status and linked to this issue.

gulshan commented Oct 26, 2017

Proposed .net compatibility pack includes System.Xaml with maybe status and linked to this issue.

@Mike-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE Nov 20, 2017

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

Mike-EEE commented Nov 20, 2017

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

@terrajobst

This comment has been minimized.

Show comment
Hide comment
@terrajobst

terrajobst Nov 20, 2017

Member

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.

Member

terrajobst commented Nov 20, 2017

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.

@terrajobst terrajobst modified the milestones: 2.1.0, Future Nov 20, 2017

@juepiezhongren

This comment has been minimized.

Show comment
Hide comment
@juepiezhongren

juepiezhongren Nov 21, 2017

@Mike-EEE it seems that xamarin.wasm is to arrive.
mono/mono#5924 (comment)

juepiezhongren commented Nov 21, 2017

@Mike-EEE it seems that xamarin.wasm is to arrive.
mono/mono#5924 (comment)

@Mike-EEE

This comment has been minimized.

Show comment
Hide comment
@Mike-EEE

Mike-EEE Nov 21, 2017

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 DependencyObject required), and also protobuf-style parametered serialization.

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

Mike-EEE commented Nov 21, 2017

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 DependencyObject required), and also protobuf-style parametered serialization.

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

@lokki

This comment has been minimized.

Show comment
Hide comment
@lokki

lokki Jul 19, 2018

@danmosemsft will Workflow Foundation xaml be supported in SDK projects as part of 3.0 desktop initiative?

lokki commented Jul 19, 2018

@danmosemsft will Workflow Foundation xaml be supported in SDK projects as part of 3.0 desktop initiative?

@danmosemsft

This comment has been minimized.

Show comment
Hide comment
@danmosemsft

danmosemsft Jul 19, 2018

Member

@lokki I don't know of plans . @terrajobst @karelz?

Member

danmosemsft commented Jul 19, 2018

@lokki I don't know of plans . @terrajobst @karelz?

@weitzhandler

This comment has been minimized.

Show comment
Hide comment
@weitzhandler

weitzhandler Jul 20, 2018

Collaborator

@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

Collaborator

weitzhandler commented 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

This comment has been minimized.

Show comment
Hide comment
@Silic0nS0ldier

Silic0nS0ldier Jul 20, 2018

@weitzhandler This issue makes A LOT more sense to me now. Thanks for the clarification.

I can see having System.Xaml included in the .NET Standard being useful, particularly alongside XAML Standard.

Silic0nS0ldier commented Jul 20, 2018

@weitzhandler This issue makes A LOT more sense to me now. Thanks for the clarification.

I can see having System.Xaml included in the .NET Standard being useful, particularly alongside XAML Standard.

@birbilis

This comment has been minimized.

Show comment
Hide comment
@birbilis

birbilis 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)

birbilis commented 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

This comment has been minimized.

Show comment
Hide comment
@weitzhandler

weitzhandler Jul 20, 2018

Collaborator

@birbilis not enough. Same XAML has to render equally in all platforms.

Collaborator

weitzhandler commented Jul 20, 2018

@birbilis not enough. Same XAML has to render equally in all platforms.

@birbilis

This comment has been minimized.

Show comment
Hide comment
@birbilis

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

birbilis commented 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment