Runtime: Port System.Xaml to .NET Core

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

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

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

@terrajobst you are my hero. :heart: :heart: :heart:

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

[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

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

Fair enough :smile:

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

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

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

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

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

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)

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. :stuck_out_tongue: This is obviously not true because you cannot use UWP Xaml in .NET 4.6 (nor would you want to :stuck_out_tongue:).

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

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

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.

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

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.

OK cool... thank you for the info. :+1:

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

I hope you guys can do it ! :)

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

+1 for porting System.Xaml over to .NET Core.
I hope to see one single unified XAML dialect (.NET Xaml, UWP Xaml, Xamarin Xaml) being used on all platforms in the future.
It think a .NET Core Version of System.Xaml is necessary to achieve this.

+1

To avoid mass notification alerts, we now have a new way to +1 the individual comments on GitHub, in order to show our interest / reaction for the topic at hand:

Haha @jasonwilliams200OK I for one do not mind mass notification alerts from community members expressing their rudimentary interest in a powerful, cross-platform System.Xaml solution. :angel: Maybe other topics I would share your pain/annoyance/frustration, however. :wink:

Valid (and valuable) point, in any case. I've added my :+1: for the cause.

@jasonwilliams200OK

Thanks for calling this out!

FWIW, I just invited the Xamarin.Forms team to join the conversation here:
https://bugzilla.xamarin.com/show_bug.cgi?id=26740

Or if anything, make everyone _here_ aware of the conversation _there_. :smile:

Got some great discussion going in the comments of this post:
https://blogs.msdn.microsoft.com/dotnet/2016/05/06/net-core-rc2-improvements-schedule-and-roadmap/

Basically JSON vs Xaml for the new project system that appears to be underway for Visual Studio (hooray!). Feel free to join in. :) So glad to see that this is getting another look.

@Mike-EEE, also have a look at this roadmap: https://github.com/dotnet/roslyn-project-system/blob/master/docs/Roadmap.md. The new Roslyn powered project system is going to be .. precious.

whoa... crazy that I am just hearing about this now. this must be what Scott Hunter was referring to in the aforementioned blog post in regards to more information forthcoming in a future post. Good to see. Roslyn power grows. Although, I would feel more comfortable seeing a few issues for Xaml-serialized project definitions. :wink:

See the readme of that repo: https://github.com/dotnet/roslyn-project-system#welcome-to-the-roslyn-c-and-visual-basic-project-system (and the link to VS MSDN blog), it seems like we would be able to replace various components using MEF, which would make it possible to insert an additional serializer to parse project definition written in XAML. Personally, I have grown to prefer JSON over XAML/XML when it is matter of describing the project properties and dependencies etc. as JSON is less noisy (well, YAML is less noisier than JSON and the lang standard supports comments unlike std-JSON, but in dotnet world, YAML and other langs with indentation-aware syntax are yet to gain traction)

Personally, I have grown to prefer JSON over XAML/XML

SECURITY! REMOVE THIS MAN!!! Ahem, I mean... :)

I'm all for taking the best of both worlds. @SuperJMN and @Grokys might speak more to this, but I believe efforts are being made in OmniXaml to make it less verbose and chatty.

My problem w/ JSON isn't w/ JSON per se, but its design approach which also was the basis of .NET configuration (which I assume was its inspiration), and that is, the object's schema is "yet another artifact" that the developer has to manage/maintain and _not_ the class definition. That is, in Xaml programming (as you know!) the class definition _is_ the document schema. As a result, this lends a very natural feel to the development of the document, and also helps/assist with tooling as well.

Not to mention developer sanity. :smile: Nothing infuriates me more than having to chase down some obscure schema document and figure out how to install it and get the simplest intellisense to work.

The other issue I have with JSON is again not JSON-specific, but more of the web mindset and that is naming convention. .NET configuration suffered from this too. That is, you might be defining a POCO such as:

public class MyPoco {
    public string Property {get; set;}
}

And its JSON (or app.config) would look something like (and you can school me on this if I have this wrong!):

{
 { "property": "Hello world I have inconsistent naming conventions!" }
}

Here again Xaml is aligned between class definition and its serialized counterpart, which is why I prefer it.

I do have to say that .NET Configuration was the WORST because its design yielded four artifacts for every configuration entity:

1. The element in web/app.config
2. The .xsd file that you had to somehow magically link to the web/app.config (I never got that to work!)
3. The ConfigurationElement and/or ConfigurationSection elements that took the values from app/web.config (and mapped the inconsistent camelCase to PascalCase -- oh the insanity!)
4. The POCO that ultimately got wired in from the configuration element. (WHEW!)

I have not studied JSON's project design enough to know if there is a POCO object that is being serialized with the .JSON document or if the extraneous mapping that is outlined above is occurring as well. I would love to hear if you know the answer to this.

In any case, Xaml improves upon this design by only requiring two artifacts:

1. The class file (.cs)
2. The data file (.xaml)

Finally, thanks for that link to the readme! I am once again "that guy" who does not do the very thing that file asks. :laughing:

if there is a POCO object that is being serialized with the .JSON document or if the extraneous mapping that is outlined above is occurring as well. I would love to hear if you know the answer to this.

I think if you consider [DataContract] and [DataMember] attributes, then the .NET framework (on BCL level) is aiding JSON and other data serailizers. However, there is no native/lowlevel JavaScript object literals <-> C# POCO transition support by compiler as JSON to JavaScript (and many other langs) or CSON to CoffeeScript. However, unlike XML with all its XPATH XQUERY XSLT ties, JSON has the concept of schema to validate the data and JSON.net supports it like a champ.

For C#6 and above, take a look at these issues/proposals https://github.com/dotnet/roslyn/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+author%3Agafter+dictionary, especially https://github.com/dotnet/roslyn/issues/6949 and follow the links within. With the new C#6 dictionary initializer syntax and these proposal, it seems like C# is semantically becoming more JSON friendly.

I do have to say that .NET Configuration was the WORST

Agree, you may also enjoy the "Configuration" and "IOption" pattern introduced by ASP.NET team as a plug and play package: https://github.com/aspnet/Configuration, https://docs.asp.net/en/latest/fundamentals/configuration.html, which supersedes the old notorious XML-bound configuration manager.

JSON has the concept of schema to validate the data and JSON.net supports it like a champ.

Sounds like a class definition as schema. :) :) :)

it seems like C# is semantically becoming more JSON friendly.

Haha well to be sure, _any_ object is already JSON-friendly. JSON is great for doing what it is intended to do: notate object definitions in a concise, human-readable way. And there is no doubt that JSON.net does a great job of meeting this objective. When you get into describing _applications_ then we start getting into the area where this conversation starts to get, um, involved for lack of a better word. :smile:

In the end, there are two scenarios here (to me, at least): describing objects that are meant to be transferred between service boundaries (lightweight) and describing the applications that create those objects (significant). I personally like to strive for consistency in every way possible and minimize context-switching. As long as we keep our options (IOptions? :laughing:) open and allow developers to choose the format that makes the most sense to them (and allows them to use the tooling that makes them feel the most efficient!) then we all win here. :+1:

UWP XAML has fewer features in comparison to the classic .NET WPF XAML. One of the features I miss most are TypeConverters.

I tried to create my own TypeConverter as suggested here https://msdn.microsoft.com/en-us/library/bb546926(v=vs.90).aspx (the article is for WPF TypeConverters)

In UWP I get with this “Unknown type 'car' in XML namespace 'using:App2TypeConverters'”

        <ListBox>
            <local:car></local:car>
        </ListBox>

Is it really not possible to add a custom TypeConverter in UWP? Or is there a workaround? I read somewhere that the XamlCompiler is using the internal IServiceProvider to register the TypeConverter. Maybe it can be registered with it somehow ?
I'm also interested in learning more about the background regarding XAML compilation. Will XAML still be generated to BAML? Can we somehow hook into the XAML compilation?
So, please open System.Xaml.

Sooooooo... does this mean that System.Xaml is finally going to join the party??? :smile: :smile: :smile:
https://blogs.msdn.microsoft.com/dotnet/2016/05/27/making-it-easier-to-port-to-net-core/

I'm going to pipe in here and say:
a) I really would love XAML running with .Net Core and
b) ifwhen that happens, it would make the most sense to use the UWP flavor, as it is already being ported to other architectures (eg the IoT push on the Raspberry Pi).

Getting WPF XAML would be amazing though, if that is possible.

In the same way that .NET core was essentially rebuilt from the ground up, based on the past the decade of learning, I think the same should be done for XAML. The evolution WPF/Silverlight/WinRt-XAML has been a complete debacle. One step forward, two back (one sideways). The promise of XAML, Expression Blend etc has never come to fruition.

I heard Scott Hunter justifying no cross-platform UI in Dotnet Core the other day by say "Well, they never turn out good. On Windows users expect a Windows looking button, on Mac a Mac button". Well I'm sorry - where has he been for the last 5 years??? The web entirely dominates UI design now and on the web there is no such thing as a "standard button" - but guess what? Users have managed to work it out. That argument simply stands against all evidence. These Web UIs now dominate commerce on the planet. But apparently that's not good enough for Dotnet Core. Why can't we have a cross platform XAML without pandering to any [imaginary] "standard platform look & feel" aspiration?

The main technical obstacles I presume would be how to interface "XAML" (Or whatever the next generation UI platform is called) with a cross platform 3D API - as we obviously cannot take a dependency on Direct3D/Direct2D on MacOS etc. But I presume this problem has been solved by Unity etc who manage to achieve that goal.

There has been so much foot dragging by Microsoft on the subject of open sourcing the XAML-family of technologies, one has to wonder if hidden within it is a secret cache of bitcoins or the private keys to microsoft.com.

Get on with it MSFT : Open Source WPF/Silverlight/WinRT-XAML and let the next golden era of UX begin.

That's pretty amazing to hear what you say about Scott Hunter, @JackUkleja. Do you have source/link for that? If what you say is true, then in addition to what you say, this shows (surprising) ignorance on several fronts:

1. This is exactly what Xamarin.Forms attempted to tackle.
2. Platform-specific (or mimicking as it were) UX/interactions/styles are a concern that can and should be addressed by themes. This is what WPF was very good at (although to your point it could and should be improved).
3. Worst of all, this doesn't place any confidence into the talent pool that successfully created WPF, arguably the greatest presentation framework of all time. Are you saying that they can no longer solve this problem? Or at least work the same magic that made WPF so successful in a cross-platform manner?

Good UX is good UX. As you point out, the web demonstrates this clearly. Native application users are definitely conditioned to a certain look and feel for their native interfaces, but again this should be solvable from a theme.

Imagine being able to view a an application on an iOS device in a Droid "skin" (complete with behavior) and vice versa. This was/is possible with WPF and is exactly the sort of thinking that should be carried going forward. That is, the look/feel/experience shouldn't get in the way of developing and designing the application. You should be able to apply a theme, and whalah, "it just works." This unfortunately was/is a detractor for Xamarin.Forms in that while it does account for different platforms, there is a lot of friction involved with making sure everything works as expected on each target platform.

@Mike-EEE I'm pretty sure Scott Hunter said words to that effect on this dotnet rocks episode: https://www.dotnetrocks.com/?show=1291

Re:

"the talent pool that successfully created WPF, arguably the greatest presentation framework of all time"

...my understanding is a a large number of the original architects some of those involved with WPF left MSFT and went to Google and have been involved with Angular. Lots of ideas from WPF are appearing in Angular and related frameworks such as templating. But no matter what way you slice these web frameworks I think you will always have the smell of HTML/CSS in the background. Not all UIs make sense being document/semantic based and that is HTML's nature, which is why I reckon the world still could make use of "XAML core".

[jack...do not think that data is correct about google and WPF architects]

@rrelyea That was my understanding but I may be mistaken. I could have sworn I read that some of the WPF team worked on Angular though....Ian Ellison-Taylor among others? (Although it appears he is back at MSFT now...)

smell of HTML/CSS in the background

The more conformance and convergence towards unified HTML CSS standards or any kind of standards in that regard (C, C++, JavaScript), the better place this world would be. Instead XAML with its unique feature, can render itself as a superset framework to HTML+CSS stack etc. or simply as an alternative front-end engine to ASPNET's Razor: https://github.com/aspnet/Razor/issues/78 :bulb:

@jasonwilliams200OK FWIW/FYI there is already a HTML/CSS "standard" port of .NET in JSIL. All of its output is 100% HTML5-compliant and runs in any modern browser. This is the sort of thinking that we should aspire to, of course (and should have been the thinking since Silverlight's demise back in 2011, but I digress).

That is, (to your point I hope) the ideal/ask is that .NET developers should only have to deal with .NET/C#/F#/VB.NET and never have to touch the CSS/HTML/JS, much like how Xamarin .NET developers do not have to touch the underpinnings of iOS/Droid (whatever _they_ are. :wink: ).

@Mike-EEE, in superset languages (TypeScript to JavaScript or Less to CSS), we can use the subset lang code in super-set in the same file, but not the other way around. So the concept of superset goes bit beyond how phonegap, cordova etc. function. :)

Haha yeah @jasonwilliams200OK I just want to make sure we don't end up making a special case for our approach/strategy with getting .NET back into the browser. Touching CSS/JS should be viewed with the same disdain as touching binary. :stuck_out_tongue:

As an example, there is also another project Fayde that does use Xaml (yay), but is also dependent on TypeScript (boo). This is the way NOT to do it, as you ultimately end up with two incompatible code bases -- one in TypeScript/JS for client code, .NET for everything else -- which is very expensive in both time and resources.

alternative front-end engine to ASPNET's Razor

Razor is just a template engine in my opinion. In fact at that link you mentioned it says "...that you can choose from long list of front-end templating engines to code against."

I had even heard some comment from MS against special C#-like syntaxes like Razor inside the HTML page, in favour of frameworks that use custom tags instead

btw, there is also Bridge.net (http://bridge.net) and other C# to Javascript compilers that could be combined with XAML solutions like Fayde

Re XAML on HTML5/JS/etc. There is an interesting project Granular which is reimplementing WPF. It uses Saltarelle to compile to JS. A live example is here.

That Granular is pretty fantastic, @ethanhs. That was one I was not aware of. Since it has taken the same approach CSHTML5, JSIL, Bridge.net (that @birbilis mentions), it suffers from the same problem of not being able to share code between server and client through the use of PCLs, which is really the only viable way to do so these days.

And really, as great as that project looks, it pretty much sums the hellscape that .NET developers have had to endure since the demise of Silverlight. It and about a dozen others do "somewhat" of a job of making .NET work in the browser, but not quite the entire experience that those with Silverlight experience expect.

There has yet to be a single, solitary unifying solution that causes developers to forget Silverlight. We're getting closer, though. I hope, at least. WebAssembly seems promising but I haven't seen/heard any significant developments in a while now. The JSIL-driven port/initiative seems to have slowed down somewhat and hasn't had a checkin since last October.

Hopefully we'll have a breakthrough here in the near future. I would love to see an announcement made at next year's //build stating as such. :heart: :+1:

That would be one of the best things of the past few years happening to XAML.
Vote here!

Cool @bbougot. There is also another vote as well, that _finally_ got some attention, after nearly 15 months of existence, not counting for the nearly 3 years of not recognizing a terrible Xaml system to begin with (but I digress!):
https://wpdev.uservoice.com/forums/110705-dev-platform/suggestions/7232264-add-markup-extensions-to-and-improve-winrt-xaml

(Seriously, 15 months to even recognize a vote for a most obvious of problems? What is the UWP team doing over there??? When will the Visual Studio or .NET team take over and right the ship??? What will it ... oops, that right, I was digressing...)

Also, don't forget to upvote this thread. It's doing pretty well @ 60 currently, especially considering that this issue started before we had such fancy amenities such as GitHub Reactions. :smile:

Xaml is the only one with the potentialilty to unify the entire client ecosystem!
Please get rid of the DirectX, please hug OpenGL,!
UWP is to run on PC, on phone, on website!
Viva Xaml!

So, civil question here @terrajobst, @harikmenon, and @karelz (I see you have added a tag recently so congratulations, I'm pulling you into this!). Out of simple curiosity, I decided to get a little adventurous and check out the advanced (or maybe not) GitHub filtering on this repo. Thinking that there were a lot of votes and what not for different issues.

Here is the URL that I am using:
https://github.com/dotnet/corefx/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc

It seems as if this issue has 82 upvotes currently, and if I am correct, the next closest item in the list is at 17. That makes this issue by far and away the most requested/voted for issue in this repo, correct?

If so, I was curious if this has any bearing on your priorities and/or planning. Clearly this seems to be a _very_ popular ask/item now (again, if I understand correctly), so I am thinking it perhaps would be nice to hear maybe an update or check-in with regards to possibly starting a conversation towards progress in making this issue a possibility.

It would be great to get any perspective/context here, and/or if I have something completely misunderstood in regards to customer demand. It happens. 😄

Our .NET Core engineers are heavily focused on .NET Standard 2.0 (also high customer demand) – see details here and here. We will look at other libraries not in that list after we get .NET Core up to the latest standard.

Thanks for pointing out the upvotes query!

Thank you for your response @karelz! Much appreciated. 👍

👼 👼 👼 I will leave this right here in case anyone would like to like/retweet. 👼 👼 👼
https://twitter.com/MikeEEE76/status/776769805722521600

I have been working with xaml since the version 3 of .net, I felt the downsize of with silverlight and even its death. I am someone that love changes for improvement to make things better and more useful. But now with the UWP, I find regress instead of moving forward. Don't mind all the new features which if feel there are great, but in the lacking of the full xaml support like desktop app has. I been trying to make a new app in UWP, and I learned the hard way that everything I have learn has changed again, I cannot find much support on line, as where the xaml library has move to. For example the adorner which was under the framework is not there anymore, the x:static for the properties that don't work, you have to search for hours to find an example or what to do. There are no link to show the from of the old xaml to the new UWP...

@giworking It's obvious that MS should pay attention to client development! As Satya Nadella is quoted,azule is the core and the future of MS, The strongest energy to boost azule is the entire .net ecosystem. Compared with java, client side is almost the only weapon to persuade coders and business to embrace MS's cloud(In China, .net is really at a catastrophical condition, people talk about java and react, "what is fk st xamarin?".....). So, as a chinese coder, when i see xamarin , uwp, typescript and cshtml5, i know that it is possible to unite the entire client-side into xaml+C# mode, but why our MS friends don't see the opportunity to get back the chinese market share with if?

Wow, this issue is now over 100 upvotes! Thank you so much to everyone who has shown their support. If anyone is interested, there is a really (really!) great article by @terrajobst complete with his tremendous trademark developer engagement in the comments here:
https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/

(Seriously, every MSFT employee who posts a company-based blog post should follow Mr. Landwerth's lead on how to post and follow up with the inevitable, innumerable, and countless comments that arise afterwards. He is really tops with it all and it seems like far too many MSFT authors simply let their posts dry out and leave the questions for dead, which of course is a terrible way of treating your audience!)

Anyways, definitely worth the read if you haven't already, especially the comments. This brings me to why I am posting now as _I am very pleased to see this issue mentioned in the comments along with the passion/desire to bring System.Xaml into the .NET Standard/cross-platform era_. 👍

154 upvotes... and counting. 😎 Next highest issue is at 25, for reference. #squeakywheel

This needs be done. Get on it!

We have a @ReactWindows application targeting WPF that we'd like to use .NET Native on to dramatically improve the first-time download/install experience for our tens of thousands of Windows 7 users. We also have future plans to bring React Native to Linux and potentially re-use @ReactWindows shared code but target Xamarin.Forms.

Having System.Xaml (and other type/method/assembly dependencies of WindowsBase, PresentationCore, and Xamarin.Forms) available in NETCore vNext is critical for this strategy. We can work around this deficiency by re-authoring and re-targeting the existing assemblies, or by filling in missing types/methods in Mono's System.Xaml and building it for .NET Core, but would really prefer Microsoft step up and provide what is necessary to the platform.. /cc @rozele @pre10der89

@matthargett Good luck on this. I beat this issue to death when I was looking at bringing workflow to .net core. Even went so far as to reach out to the xaml team. They are not even remotely interested in opening System.Xaml. I don't understand why - there's certainly nothing worth protecting in there.

May be this will be considered after 2.0 release at the end of April.

Guys, again, we don't need System.XAML to make WF ported to netstandard1.x... There is already a good work from @dmetzgar in which the core of WF work. The major missing piece is Transactions which I believe is comming back eventually in netstandard2.x.

The major guideline from @dmetzgar port is to not have any kind of design language tied to the core and having basic primitives so people can serialize the workflow whatever they want and later on, create designers on top of it.

Of course that this approach will lead on non-backward compatibility with current XAML-based workflows, but believe me, move anything to .Net Core IS a major breaking change, so people need to understand that.

There is OminiSharp around that could be leveraged for the XAML designers but again, design/serialization is some out of the WF core. It must be slim as everything else with .Net Core.

I would say that this issue made out and loud that people want to move WF to .Net Core, I just think that complain with System.XAML team to OSS it, is just not being productive. XAML team has other priorities and it is core for Windows/UWP/Xamarin business so don't expect it get OSSed so soon. Instead of that, I would ask @dmetzgar to make officially public the WF repo unders .Net Foundation, and guide the community to get it up and running without set any timeline or promises on get done to netstandard2.x release. It would be an on-going work driven by his team, and helped mostly by the community that clearly want to help and make it out.

Look at how fast things evolve in Orleans project... It was a Microsoft Research that got OSSed last year and it is one of the biggest and most active repository on .Net Foundation and it is mostly driven by community efforts (it still have a MSFT team full time working in it).

Anyway, IMHO, I think we need stop yaming and start doing something. It is clear that @dmetzgar team has no bandwidth to work on that as their main concerns is to support major users of WF, which are basically Sharepoint big deployments who has no plans to get to .net core whatsoever. So it must be a community driven (supervised by @dmetzgar's team) effort.

Guys, again, we don't need System.XAML to make WF ported to netstandard1.x...

@galvesribeiro that might be true, but this issue is to get System.Xaml ported over to .NET Core, of which it is by far and away the most requested feature in the repo where the .NET team is soliciting feedback. If you do not listen to your feedback, then why solicit it? Anyways, WF is simply _one_ of the scenarios that a System.Xaml port would satisfy. As you know (or should!) System.Xaml is capable of much much more.

XAML team has other priorities and it is core for Windows/UWP/Xamarin business so don't expect it get OSSed so soon.

Yeah, that is sort of the problem here and what we are asking to change. :) Also, I am not even sure there is a "Xaml Team" any more these days, is there?! It truly feels this technology has been shuttered and we are starting to get the runaround on it.

Anyway, IMHO, I think we need stop yaming and start doing something.

100% agree. FWIW, @SuperJMN just released OmniXamlv2.0, so there are some community efforts underway that can be leveraged while MSFT prioritizes their energies and efforts around this issue (which, incidentally are going on for about 11 months now -- and counting).

Speaking of which, here's a nice thread on exactly that (that is, MSFT's inactivity on this), with a quote from @terrajobst:

To be clear, I’m not saying that System.Xaml cannot or shouldn’t be cross-platform. What I am saying is that System.Xaml isn’t very useful outside of WPF and WF, and NuGet is a sensible proxy metric for that statement. Of course, System.Xaml could be made meaningful outside of the UI realm, but that’s a secondary step. I’d rather use our resources RIGHT NOW to make the foundational pieces work well and complete. Besides, by having a converged base, porting higher-level components, such as System.Xaml becomes much easier as well.

So it’s not an either-or statement; it’s a statement of order of execution.

Brushing aside the the very incorrect statement about System.Xaml not being useful outside of WPF/WF, this all sounds of project manager-glish to me, with no intention of ever getting around to this issue. My aim isn't to be critical with that statement as I am in full support of Immo and the great work he does here. However, I have been around the block enough to allow that sort of language to give me pause and put me in a wait-and-see (or rather "believe it when I see it" LOL!) stance regarding this issue.

In the meantime, I support the current efforts in .NET Standard 2.0 and look forward to what that will yield. Maybe it might be better than expected. At the very least, it sounds like we will be able to reclaim System.Xaml for .NET Core projects working on Windows platforms, which is a good enough start for me. 👍

@Mike-EEE first of all I'm sorry... I though I was replying to this https://github.com/dotnet/corefx/issues/2394 o.O Those two issues were correlated too many times that I got confused.

Second, I'm no way saying that XAML is only useful for UI. I used it for so many years on TFS builds, WF itself and lately for UI. There are a bunch of DSLs like Azure ML, and others that could leverage XAML.

What I meant to say is that I'm not seeing XAML being ported so soon to .Net Core. As Immo said, they need to get it right first with the current platforms. .Net Core doesn't even have any native image manipulation libraries whatsoever yet.

There are multiple XAML implementations ranging from fully featured WPF to weak and lack lots of features in UWP. It must be unified and stabilized before such thing got OSS. I don't speak by the teams working in it. I just think that I would not do diff than them if I had to prioritize my resources.

Regards to WF, sorry again, but my previous comment was mostly target to ones that are hoping this issue is the reason WF port to core isn't happening that fast, which is not true.

Those two issues were correlated too many times that I got confused.

Haha @galvesribeiro I cannot tell you (or am afraid to admit) how many times that has bitten me, too. No worries about it. I for one appreciate the input regardless!

FWIW, it also looks like @cwensley continues to do a great job over @ Portable.Xaml as well, having recently made performance improvements to his mono-based adaptation of System.Xaml that make it faster than the original version. Almost seems as if that could be a good starting point for an effort here, since it's probably closest to the original System.Xaml experience of all the flavors/options out there. Just my caffeine-induced two-cents for the morning.

Please port System.Xaml to .NetCore

FWIW, over 200 votes for this issue, now sitting at 202. The next highest issue is dotnet/corefx#13526 sitting at 47. Well, WAS 47... it's now 48 after my vote. :) (Go show it some love, it's a good idea.) #squeakywheel

Thanks for reminder @Mike-EEE ;-). To set expectation: We are still not yet ready to start digging into it deeply - I personally hope that by March we should be able to comment more on our next official steps, even if it is again "we don't have plans yet" (disclaimer: I am trying to communicate my best personal guess, please don't treat it as official team promise!).

When we discussed the issue a bit last time, the key question which popped was to determine which of the 200+ votes are truly only about System.Xaml vs. WPF. The assumption being that many folks don't distinguish between the two. Any suggestion how best to go about that? (e.g. creating 2 specific issues and asking folks to vote for WPF vs. "pure Xaml, not WPF")

Also it would help to have a summary list of scenarios for System.Xaml with some priority estimations (they are now scattered across long discussion). @Mike-EEE is it something you could help us put together please? (as you seem to have strong interest and deep knowledge in the area)

Definitively System.Xaml is what people want @karelz. If someone is thinking on WPF here it is not the right place IMHO. There are a bunch of other frameworks that leverage XAML like WF, TFS Build, etc which still using System.Xaml and that would give us a big hand.

@karelz I really appreciate your reply here. Thank you for taking the time to do so. As @galvesribeiro mentions, System.Xaml is more than just UI, which seems to be a key understanding that is missed by a lot of MSFT, unfortunately. It is a powerful serialization paradigm that puts it above and beyond any other serialization solution out there, especially and particularly when it comes to describing applications, which is what it is best at doing (the "A" in its moniker, after all). Unfortunately "application" has been conflated with "UI" and hence the friction here.

Overlooking this aspect was a key failure of UWP and is part of the reason why no one really likes working with it. Conversely, Xamarin seems to have understood this key aspect in its flavor of Xaml, but it is internal and not exposed as a first-class, authoritative offering should be (which is pretty much what this issue is after here).

TBH, @cwensley's port of System.Xaml in Portable.Xaml seems to be a front-runner at the moment. He not only has ported Mono's System.Xaml (maintaining its overall familiar API), but has added new features and has actually improved its performance to be _better_ than that of System.Xaml.

In my view, this issue could be as simple as working with @cwensley to make what he has got going the authoritative cross-platform Xaml library to use going forward.

Outside of this, is where it gets tricky and might be adding to your (understandably) complicated view of this issue. As System.Xaml does provides an expressive and powerful language to describe applications (again, not just user interfaces), it also has some great tooling support baked into Visual Studio (and of course Blend). So ideally it would be awesome to continue that same great experience and somehow keep Xaml's designer experience in a cross-platform way, but personally that is asking for a cherry on top of the cake of awesome we're discussing here. :)

Also, to reiterate here, Xaml's promise (and delivery) was also an improvement of the development workflow between designer and developer. I like to think we can ultimately take this one step further and improve the process between development and _devops_. That is, I would love to see a world where devops works in beautifully designed application configuration editors (powered by Xaml) to manage and maintain deployed applications.

_The whole idea here is reducing overall cost in application development from coding to deployment. Working with pretty editors and designers is cheaper (from a resource perspective) than having to find and employ someone who has to get their hands in code (and/or scripts) to make magic happen._

I share this with you as a vision perspective, just so you are aware. I am not sure how interested you are in hearing this, however. 😉 So, if this is simply a "what would it take to close this issue and make you go away?" I would suggest exploring the possibility of working with Mr. Wensley and see if we can leverage his great work thus far (or if he is even open to doing so). If there is a way of angling this so that it can be the authoritative cross-platform Xaml package for .NET Core Wave 2's release (around May or so?) then even better. :)

Thanks for info, I am definitely interested. I also feel that my previous question(s) didn't come over as I intended, so let me try to point out few things:

Yes, I am definitely interested in details. I don't think anyone is disputing Xaml != WPF on MSFT side. I definitely didn't try to do that. I just know what I don't fully understand, and I am trying to fill the gaps - i.e. fully understand the motivation and need of the scenarios of "pure Xaml".
(BTW: I don't quite understand your devops scenario and how Xaml is the only/best thing to help there? Or how it is actually used in the scenario at all?)

I am not here to try to close this issue. Please! That even didn't cross my mind. I am here to help community to summarize the ask, such that it can be discussed with the right people (think directors in this case). Yes, part of it means that I (and/or couple of other MSFTs) have to fully understand the ask to represent it higher up - hence my questions.

I admit, I am a good example of a person who didn't distinguish Xaml and WPF before he saw this issue. From random chats with others on .NET team, many know that Xaml != WPF, but they don't see the "huge value" of having pure Xaml which is being pitched here - therefore my questions above about the scenarios. The scenarios will help me/us understand the motivation better and tell/sell the story better. (I hope it is not a surprise that when there is no clear story, no one feels anxious to fund it :) - the story is a prereq for funding)
So let's come up with the elevator pitch to move it forward.

Regarding @cwensley's work - it's great to hear there might be some not so expensive solutions. But again, it would truly help to first understand the background and WHY, before we jump into solution. I hope it makes sense. (I am not trying to be dismissive or anything - just repeating that it is easier to move things forward when the WHY is understood and agreed upon)

@galvesribeiro If someone is thinking on WPF here it is not the right place IMHO

I don't share your confidence that all the 200+ people who voted truly understand the Xaml != WPF to such details. Also I guess that at least a few look at it - yeah, let's get Xaml first, it will be then easier to ask for WPF. So their scenario in mind all the time is WPF, while "pure Xaml" is just first step towards it.
And maybe I am wrong (although I am at least not the only person on .NET team with these doubts) ...
Another angle might be to break down "pure Xaml" into list of scenarios (WPF, devops above, maybe couple of more?) and then ask folks to vote for them - Which of them truly matter to those who voted here? What they truly want?
(This is not a delay tactics, or anything evil, I am trying to understand the "customer" here. I hope that makes sense - if you have better suggestions how to get to such data, speak up, I am open to alternative approaches)

EDIT: As usual, if you think I am not approaching the problem the right way, please say so. I'm trying to do my best here to help - with the best intentions. I don't suffer from the illusion of knowing-it-all, or thinking that I am smarter than everyone else.

@karelz There are a bunch of UI frameworks that are reinventing the wheel and writing their own markup languages just because XAML isn't cross plat even if they don't like WPF at all. Avalonia is one of the top ones. They use Omnisharp when they could be leveraging native XAML instead.

Workflow Foundation is a big user/customer of XAML and people on Port WF to .Net Core thread always ask about it.

So yes, I agree with you that we should establish the expectations or draw a raw feature set on what is expected from the cross-plat System.Xaml along with the desired usages like for example UI and WF.

@karelz

Also I guess that at least a few look at it - yeah, let's get Xaml first, it will be then easier to ask for WPF. So their scenario in mind all the time is WPF, while "pure Xaml" is just first step towards it.
And maybe I am wrong (although I am at least not the only person on .NET team with these doubts) ...

So... what's the problem with that? A WPF-like cross-platform solution could be quite a good thing. Xamarin can't do cross-platform desktop GUI.

@jnm2 it is not bad - but if that is the main (90%+) scenario, we should plan on doing both. Having Xaml without the WPF is not going to help in such case (at least not much). And it might create (potentially) invalid illusion that WPF is committed and will come shortly after.

Getting WPF / GUI into .NET Core will be a huge step for .NET Core, which targets primarily server scenarios and console apps now.

@jnm2 having System.Xaml would massively help people (like myself) who are _trying_ to bring something like WPF to other platforms (https://github.com/AvaloniaUI/Avalonia).

@grokys that sounds like a reasonable scenario - can you elaborate a bit more on it? How massive the help would be? What is challenging without it?

I am also using Xaml for my (non-WPF like) cross platform desktop UI framework, Eto.Forms. This is why I created the Portable.Xaml project to begin with, and it has been working well for me and my users thus far.

I am not opposed to helping make this the "authoritative" cross platform xaml implementation (as @Mike-EEE puts it). However, keep in mind I only work on this in my spare time (;

@karelz
Not only UI frameworks, It can used in many scenes like XAML to HTML

@Kation can you share more details what exactly you mean?

BTW: I started summarizing scenarios in the top post - if your scenario is not there, please describe it and once it is understood, I'll add it there.

@karelz
WIth the powerful XAML editor in visual studio, we can quickly create custom components content.
Then, I think we could use XAML to generate HTML contents in some specially scenario, even more SVG contents.
This is a semi-finished XAML to XML framework for .Net 4.5. https://github.com/Kation/WebPresentation

I don't get why you want to generate HTML or SVG from XAML. What's the value of XAML here?
Is the value that it has a nice VS editor? There are also HTML editors, why not to use those directly?
Or am I missing the point entirely?

@karelz
Because I want to generate contents like WPF with template and style in some projects.

@karelz thanks again for the dialogue. I for one very much appreciate it.

I don't suffer from the illusion of knowing-it-all, or thinking that I am smarter than everyone else.

Oh, I envy. 😉

So their scenario in mind all the time is WPF, while "pure Xaml" is just first step towards it.

Yeah, this is again the conflation I mentioned. Xaml is a serialization paradigm, pure and simple. You can define and describe an application -- and its containing components -- in it. To start with, here is an example of a _console application_ described in Xaml:
https://github.com/DevelopersWin/VoteReporter/blob/master/DevelopersWin.VoteReporter.Application/Program.xaml

You can see that there are commands described in Xaml that provide instructions on what to present to the user through the use of console inputs and outputs. This has nothing to do with WPF or "UI" (although technically this is the UI in the sense of the CLI being UI, but hopefully you can spot the difference). Additionally, you can see that I make use of markup extensions and static member declarations right in the file. This is something that I have not seen in JSON or any other data format. This is truly the power of Xaml, IMO.

As another another example of a "Pure Xaml" scenario, here is file that I am proposing for a new format-agnostic MSBuild:
https://github.com/Mike-EEE/Stash/blob/master/MsftBuild.Model/SampleFormats/Xaml/Processor.xaml

(if you go up a level you can see the other formats that do the same thing, this just happens to be the Xaml version)

This is the processor file that again is a set of (System.Windows.Input.ICommand) commands that describe the steps to take in a theoretical build process. Again, no WPF or UI, but you can see that it does emit messages out to the console.

One feature I want to point out here that I mentioned earlier is the built-in tooling in Visual Studio that I get from this file:

Without doing any work or defining any external schema, Visual Studio simply "lights up" and provides property editors complete with dropdowns and other designer interface based on the class schema of the file that I am working with (this will hopefully make the devops scenario easier to understand).

In addition to the processor file, here is the theoretical project or input file that could be used to send to the processor:
https://github.com/Mike-EEE/Stash/blob/master/MsftBuild.Model/SampleFormats/Xaml/Project.xaml

Here I try to hit the point home with _markup extensions_ used to provide a version (conceivably from an external file) and also to use a query to provide the files collected to build (note that maybe you might not want to actually do this in a final build system, but I wanted to demonstrate its possibility).

BTW, this example code is fully operational, so you should be able to get the SLN from that repo and run the Xaml version, the results should look like something like the following:

(Note: Works on My Machine so your milage may vary. 😄)

BTW: I don't quite understand your devops scenario and how Xaml is the only/best thing to help there? Or how it is actually used in the scenario at all?

Yeah, I debated whether to get into that, as I felt my post was getting a bit lengthy. Hopefully now the visual designer component above can help illustrate what I am pawing at here.

Please know and note that to me this is the ultimate end game and why I am so gungho about all of this. _The reason why is that it ends up reducing the total cost of ownership for an application over its lifetime._

So at the core here, what we are talking about here is POCO-based development, where editing and designing occurs on POCOs used within an application process. As we know, a developer and designer will work on a Xaml file that describe POCO elements that deal with the UI domain (the here is the traditional "WPF" of "Xaml" if you will).

In my world, I would like to see this process extended so that development delivers Xaml files for devops to use to manage/maintain applications that have been deployed to a live environment.

You can think of this as live configuration files. How they are loaded will have to be ironed out, but the end result would be something like what you see in the screenshot above in Visual Studio. Instead of the end (devops) user being forced to put their hands in code (or rather, having an organization being forced to hire the expensive talent/skillset required as such), they instead work with constrained, validated visual editing controls to configure and maintain the application.

_The idea here is that because of the effort (and skill) required to do this rather than being required to know and understand code, the cost of maintaining an application after deployment is reduced considerably._

One aspect that I haven't mentioned about this is that those controls are actually customizable. Visual Studio has an (albeit aging) extensive API to define the visual editors attached to those POCO properties:
https://msdn.microsoft.com/en-us/library/microsoft.windows.design.model.designmodevalueprovider(v=vs.90).aspx

This is all available right now in Visual Studio without any additional work, overhead, or effort. So the ultimate idea here would be to create a suite of powerful editors and designers to help not only in the development process, but ultimately the devops process.

Again this is all visionary and without any actual real-world basis (yet). To be sure, this isn't totally my idea but is inspired by the patterns and practices group with their Windows Forms based Configuration Editor. I simply took this sucker one step further and see using that through the power of Xaml.

Please let me know if you have any additional questions around this @karelz. Again I appreciate the dialogue. Not only does it provide the opportunity to share, but it also gives an opportunity to validate my ideas and beliefs. And with getting back to the idea of knowing it all (yes, I am guilty 👼), I try to keep an open mind about things and realize that I do not have all the answers. This is definitely a process I am continually trying to get better at doing. Thanks again!

@karelz - Avalonia currently uses OmniXaml as its XAML engine, and while this works quite well, there are still bugs and missing features. Like Portable.Xaml, OmniXaml is maintained by a volunteer in who doesn't always have a lot of time to work on it.

If in fact you decide not to open System.Xaml, maybe releasing your test suite would be a good compromise - at least in that way we could ensure that the 3rd party implementations such as OmniXaml and Portable.Xaml were as compliant as possible.

I think what .net ecosystem needs is a default human readable serialization format- something like JSON in Javascript world. This format should use donet data types and directly use POCOs as schema. Then that format can be used to describe POCO objects. These descriptions are strongly and statically typed. Which can be a UI layout, runtime app configuration, project/workflow description or even for communication between two .net programs. And even communication with other ecosystems(like web/Javascript) is also possible, given they implement the format. But it should be designed around .net ecosystem. That's why JSON/BOND/Protobuf/XML is not enough.

Historically, XAML was somewhat fulfilling the responsibility. Now the question is, how good it is for this role. If it is good enough, then I think XAML should make into netstandard and then .net implementations. But, if possible, other formats should also be taken into consideration. I think last week, http://www.ammyui.com/ came out. A UI description format focused around simplicity but translates to XAML. Because, XAML was not simple enough. I myself has proposed one format in roslyn repo- dotnet/roslyn#16648 based on (object, collection and index) initializers. And my proposal was actually taken from (and then slightly modified) this blog post by @bricelam of the Entity framework team. Both his post and my proposal thread have some examples.

My point is, there should be a default format for .net, be it XAML or something else.

@grokys I did want to mention OmniXaml, and have invited @SuperJMN to the conversation here, but it doesn't seem he ever wants to participate. Not sure if it is settings or what (I have also made an attempt in the gitter as well -- since you work with him, perhaps you can have better luck with dragging him in here 😄 ). OmniXaml is of course definitely welcome to this conversation as well.

@gulshan +💯 👏 👏! Ha ha. Part of the confounding part of all of this is that Xaml IS a MSFT format and technology. With all of the investments and tooling built around it -- both with MSFT and in enterprises, it is indeed incomprehensible why there seems to be gap in ensuring its continuity so that existing efforts and investments can be leveraged.

That said, I like what I see with Ammy and I continue to have an open mind about this. Or attempt to have one. 👼

I think it's important reiterate why we even bother with data files to begin with, the primary value in using data formats is:

• Imperative Language Agnostic. Use of the files do not require you to know a programming language.
• Designer/tooling friendly. _Using a visual designer and/or enabling a visual designer experience with your product leads to lower TCO_.

That said, what is personally important to me is:

• Developer/designer integrated workflow
• Visual designer experience for hand-editing files.
  
  
  
  • PropertyGrid (Properties Window) with extensible editor API as discussed above.
  
  
• Markup extensions
• Cherry-on-the-cake of awesome: Ability to leverage all of the above within scenarios outside of development (devops example above).

If all of these are met, then I would be willing to consider "another .NET format" but obviously I would prefer to maintain and extend Xaml as that format. It is a MSFT technology and therefore intellectual property, after all.

@Mike-EEE If a format can be deserialized to a POCO, all those features should be working, The properties window in VS appears for non-XAML scenarios as well. But one thing I have concern is, readability without any editor support. In some cases, you have to edit a config file in a remote server, and you only have vim. Compared to JSON, XML(and XAML) is not that great in this regard, IMHO.

But XAML has some unique things(actually non-XML features) like attached properties, which are hard to imitate in a simple serialization format.

I'd vote for WPF first (so I can finally say good bye to xamarin.froms), then xaml

The properties window in VS appears for non-XAML scenarios as well

Correct, but it is not nearly "lit up" like it is for Xaml, with fully customizable editing controls, etc. Correct me if I am wrong here. You cannot simply put your cursor on a property in these formats and have a dropdown render for an enum field (for instance). This experience is basically the next form and version of WinForms, which is part of the reason it is so nice (WinForms is still popular!).

Compared to JSON, XML(and XAML) is not that great in this regard, IMHO.

Yeah I agree, Xaml isn't exactly terse, and you'll hear complaints about how verbose it is. This is where OmniXaml is making its mark by providing improvements around the formatting. You are also competing with the likes of other formats altogether such as TOML and YAML and such.

non-XML features) like attached properties ...

And markup extensions. 😄 These are features of its vision.

What (I believe) you are pawing at here @gulshan is essentially a "Data AST (abstract syntax tree)". If we're talking about seriously improving Xaml (or .NET data format), then this is the way to go. It could be powered by Roslyn, even. In fact, I have a uservoice vote out for this very idea (along with a corresponding blog post). Unfortunately it's not very popular as it's sort of difficult to explain, haha. Essentially you have an AST (data) tree that can be written to any number of formats. That way developers (and tooling) can work with it according to whatever format makes the most sense (aesthetically or otherwise) to them.

so I can finally say good bye to xamarin.froms

In agreement with you on that aspect @groege. 😎

@Mike-EEE Haven't previously checked out your Data AST proposal. Yes, it is conceptually similar to the default serialization / object notation proposal for .net. The idea is hard to understand because of its abstractness. 😄

Regarding XAML, a .net-based strongly typed data serialization format will alleviate need for many XAML markup extensions. Yet there will remain some, which cannot be initialized by some expression(without constructors). I wish some of these markup extension capabilities were part of C# itself.

Well I haven't heard back from @karelz so I can only assume he has been since been perched in front of his monitor as such upon learning that you can define a Console Application in Xaml:

(Bad) jokes aside please let me know if you have any additional questions.

Also, from This Week in .NET, looks like a pretty cool engine that is brewing in .NET Core. The first comment of this post says it all. :)

@Mike-EEE I know I owe you an answer (it's marked important in my inbox & opened in browser).
So far I was able only to skim through the replies (thanks a lot everyone for all the details and insights!), but I didn't get time to educate myself on Xaml (as you point out) and read all replies thoroughly to be able to answer... sorry, too many fires and high-pris going on right now :(, I will get to it later, I promise!

All good @karelz! Very much appreciate your efforts and dialogue here.

Here's a vote for open sourcing WPF, every other version of XAML is garbage in comparison. And seriously guys, complete the loop on this, have a .net core / XAML STORE for unix and MacOS.

@Mike-EEE very sorry, I still didn't get time to get back to this issue :(

Oh man don't worry about it, @karelz I know everyone is busy right now. I appreciate the conversation more than anything. I got a lot out of my head. It's good to see it out there and to reflect on it as such. Besides, we've already put in a year+ wait on this so far... what's a few more months or so? :)

they should opensource silverlight 5 .. since their html5 move,their win8 move/winrt...& now uwp & win10 and xamarin .... COMMON!! pathetic your lost in la la land like hollywood or what...

how can one go from silverlight 5 to all those crap? HOW? how can you say you respect your users when you always break assembly interfaces.. you even rename your own nuget package and dont give an automatic way to move from the old to the new ones in nuget.. it's like your still using everyone as infinite beta tester because your too dumb to think clearly before creating the ideas and coding it.

you need to remove the need for ios/android/uwp projects in xamarin forms.. THINK there is much better ways to support multiplatform than having a project for each platform.

now bring everything under one f. framework you ass wipes( i recommend wpf/silverlight coverage and xaml language but heck if you want to bring everything into xamarin but please can you add datatypes on the style/templates.. weird omission like many and make sure your f. nucrapget work A1 for once.. why the heck would i need to install a nuget package in all dependent assemblies? same with referenced dll.. ? you have no vision... niet none... capout... all this time stuck in ms crap.. i could have built my own f. world class sdks..

i cant spend a day without MS dumping a turd in my road.. i'm seriously considering scala-js or just swift.. it's time to leave house! i'm fed up

Well it took them nearly two years, but UWP is finally spec'ing out markup extensions for their Xaml model:
https://wpdev.uservoice.com/forums/110705-universal-windows-platform/suggestions/7232264-add-markup-extensions-to-and-improve-winrt-xaml

Also of note, Noesis launched their v2.0 product last week, and it looks pretty impressive. Its Xaml system already features markup extensions (in C++, with C# on the way), and it didn't take them seven years to get to the spec. It's also free to indie developers now. Once you factor in its AmmyUI support, I gotta say that this is at the top of my list as far as Xaml models go ATM:

http://www.noesisengine.com/

Hey @karelz perhaps you might be able to comment on this. But do you know if the UWP Xaml "spec" that is happening now has any correlation to this issue? If not, do you know if it can? Crazy idea here, but it might be nice to solve two problems for the price of one if it can be helped. I've also left a message there on the UWP vote as well, but figured I would ping here as well.

@Mike-EEE UWP Xaml "spec" is likely driven by another org (I think in Windows) - asking them for details on the uservoice is probably best channel.

Yeah, I was afraid of that. 😛 I did get a reply there, but I have to be honest it doesn't make much sense to me.

From what I can grok, it does appear that they are going to continue to take a closed-door approach with their specification process. This is concerning as it would seem that this would lead to the same results as last time, ending in an API that no one wants to use or adopt.

Maybe they secretly enjoy developers complaining about their work. :)

In any case, if you are reading this and are a proponent of transparent, open-source collaboration and development, and have enjoyed being a part of the success of asp/.NET Core's initiative into this domain, please take a second to head over to the WPDev UserVoice and send them a note encouraging them to do the same. The link was mentioned earlier but here it is again for those who are reading this from email:
https://wpdev.uservoice.com/forums/110705-universal-windows-platform/suggestions/7232264-add-markup-extensions-to-and-improve-winrt-xaml

I have to call out @birbilis and thank him for his earlier contribution there. Any additional kind words of confidence that anyone could lend in promoting the process that we all use here would be greatly appreciated. 👍

sigh ... just like uservoice you get people to vote for things and in the end even if it was popular don't do anything about it!

Update:
https://github.com/microsoft/xaml-standard

I'm sure @Mike-EEE will be very pleased w/ this ;P

That is a great move. Thanks for sharing @RichiCoder1

Unfortunately, it is UI-only. Other usages of XAML like Sharepoint and WF are probably out.

But yes, at least it will help to standardize the XAML across all supported platforms.

Good move!

Hope they'll split it in layers

Eg apart from the non-UI base XAML layer I'd like to see XAML 3D layer

@galvesribeiro Looks like someones created an issue: https://github.com/Microsoft/xaml-standard/issues/23 I'd +1 it, no reason for the eventual standard to not be split out.

I'm sure @Mike-EEE will be very pleased w/ this ;P

Haha and right you are, @RichiCoder1! It's all wrong and broken and nowhere where it should be, but it's a start. ;) Thank you for letting us know. 👍

And very pleased with seeing someone creating https://github.com/Microsoft/xaml-standard/issues/23 so that I don't have to. ;) ;) ;)

Plesase, consider including WF (Workflow Foundation) in XAML Standard!!.

@Suriman please upvote!
https://github.com/Microsoft/xaml-standard/issues/23

So I hate to ask -- and I do so in the interest of being a good repo/issue citizen, but is this issue needed anymore? I mean, that repo is already clocking 50+ issues that are going into WAYYYYY more detail than this issue ever can. Looks like it already has a life of its own!

Is there a reason to keep this issue here open? Unless I am totally misunderstanding something (quite possible), I think we've accomplished the goal here w/ the Xaml Standard. It is community-driven and everything, which is most important to me, personally. :)

@Mike-EEE There is a subtle difference between the two issues; the one seems to me to be about standardizing the APIs available within XAML itself (strictly in the XAML itself), and the other is about support XAML as a .NET Standard component similar to System.Xaml.

@lokitoth definitely open to the conversation about this, as I am still trying to grok all the new pieces. I suppose it's best to start with suggesting to watch @terrajobst's excellent and informative video that demonstrates code "just working" with the new .NET Standard2.0. I personally have not wrapped my mind around how this impacts System.Xaml. My thinking was that it should "just work" but perhaps I am starting to think I am now mistaken here (ala too good to be true).

And to be honest, after reading a few of these threads in the Xaml Standard repo, I was sort of kicking myself for my earlier suggestion (☕️ the coffee made me do it, I swear! ☕️). From the looks of it, "Xaml Standard" is better named as "MSFT UX/UI Standard" as that is what is primarily being discussed in that repo. As it stands, Xaml as a powerful serialization technology is not being presented/showcased/highlighted at all (outside of the few brave voices here that have made the efforts there), which is also leading to some disconnect/confusion as well.

I personally have not wrapped my mind around how this impacts System.Xaml.

We'd need to inspect the assembly to figure out whether it's dependency tree is loadable in a .NET Standard 2.0 context. If it's pure .NET, it's likely to work (though there's a whole compile-time set of items, e.g. BAML, Embedded Resources, etc., which would to be brought into the toolchain of .NET Core)

From the looks of it, "Xaml Standard" is better named as "MSFT UX/UI Standard" as that is what is primarily being discussed in that repo.

That, I think, is more a function of it being announced in the context of UWP/Xamarin.Forms, which means developers focusing on those two platforms - who may not have had exposure to "BigXaml" - are the ones primarily contributing. Though you see a few "bring all of the WPF XAML dialect" issues opened.

Given that there's a lot of cleanup for the team to do, and that right now the rate of new issues is fairly high relative to the number of people contributing, I'd give it some more time to see where the team takes it.

@Mike-EEE @terrajobst @terrajobst @cwensley @mellinoe
I have created a issue in Xaml Standard.
https://github.com/Microsoft/xaml-standard/issues/57

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

well @lokitoth I'm glad we kept this issue intact as it was decided https://github.com/Microsoft/xaml-standard/issues/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: https://github.com/Microsoft/xaml-standard/issues/145

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.

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

@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- https://github.com/dotnet/corert/pull/4480 . Hoping for a production ready HTML+CSS+C# combo next year.

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

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.
https://github.com/mono/mono/pull/5924#issuecomment-343551464

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

https://blogs.msdn.microsoft.com/dotnet/2018/05/07/net-core-3-and-support-for-windows-desktop-applications/

@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
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: https://github.com/Microsoft/xaml-standard/issues/232

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

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.

BTW