Cross platform UX for .NET 5

[4creators]

.NET Core does not support directly any desktop or mobile UI. It was designed and implemented without such a goal at least up to v2.1.0. Nevertheless, it is a feature which potentially may expand usage scenarios very significantly. It is one of the oldest and most voted up features on Visual Studio UserVoice as well.

• Bring Windows 10 Universal Apps to Android and iOS 3 658 Votes

• Create a Ubiquitous .NET Client Application Development Model 11 213 Votes

Microsoft and Xamarin jointly own an XAML based UX code stack (WPF, UWP, Xamarin Forms, WinUI) which could form a basis for .NET 5 UX stack. Unfortunately, work on XAML-Standard has stalled despite that IMHO it would be a good place to make decision about UX in .NET 5.

Even more important Microsoft Fluent Design could be adopted in Core UX at least on Windows if not at least partially on other platforms. This would put .NET Core on bleeding edge of modern, universal xplat framework development. Currently I would prefer to run Microsoft Fluent API based app on my Mac. It was quite different at Windows Vista and 7 times (I work daily on both Mac and Windows).

One of the most important requirements would be a hardware support. Providing that MSFT and Xamarin currently use DirectX and OpenGL based technologies one should be able with significant investment create modern hardware accelerated graphics/media cross platform backend. This would as an additional benefit allow for providing modern graphics API as an alternative to outdated System.Drawing API resurrected for .NET Core v2.1.0

Related not only DotNet issues:

Port System.Xaml to .NET Core

Include WPF in the standard (XAML Standard)

Port Winforms to CoreFX

XAML Standard scope discussion

WinUI 3.0 roadmap - we need your input!

WPF, WindowsForms and WinUI (UWP XAML) are open source !!!

It's good time to start porting them to other platforms

• https://github.com/dotnet/wpf

• https://github.com/dotnet/winforms

• https://github.com/Microsoft/microsoft-ui-xaml

Last updated 2019-05-20

[KPixel]

I like this idea. However, practically, it is something that is more likely to be handled by the Xamarin.Forms team.
Maybe, the Core team would contribute some low-level constructs to make the UX framework "better" (like what CoreFxLab does).

Edit: Could WebAssembly also become a supported platform?

[galvesribeiro]

I like the idea. I've seen people (including myself) suffering with multiple UI technologies for multiple environments.

I'm pretty sure in a foreseen-able future we will see .net core ported to Android and iOS devices using the Native application as a replacement for corehost. With that being said, UI capabilities will be required.

For 2D xplat Drawing libraries (including Accelerated drawing), we have Skia for example.

In all scenarios, I believe XAML-Standard will be a good thing to move to in order to achieve an standard way to "describe" UI all together with the Fluent Design guidelines.

However, I'm skeptical that there are any plans from .Net Team to invest time on that more than just bring some xplat System.Drawing.X primitives back...

[JimSEOW]

@4creators Perhaps this discussion is of interest to you

[poke]

@vibeeshan025 WebAssembly is not a replacement for JavaScript, so most of your comment does not really make any sense. You will still require JavaScript to connect a WebAssembly with the DOM. So, no, you cannot just compile something into wasm and expect it to replace whatever you did before with JavaScript. That’s not how it works. It won’t be a UI technology.

[offbeatful]

Hey guys, just want to put my 5c here.
System.Drawing.X is essential for .NET Core development. (just came here from https://github.com/dotnet/corefx/issues/20325)

As of UI - ask web (front-end) developers. They use a lot of modern tricks like hot reload.
I personally like how things are progressing around React/ReactNative. It would be awesome to use C# to write React and then use various render engines for different platforms.

[Mike-E-angelo]

FWIW, Mono is adopting WebAssembly, so if it works in Mono, it works (or will work) in WebAssembly. That's the present idea/understanding, at least.

Also, I have to echo the sentiment on the probability of .NET/MSFT accomplishing this task. All of their focus/IQ has been placed into core/internals/framework/just-get-it-working and I think it will be this way for another year or so. But who knows, I could be (pleasantly) surprised.

My take on this is that some external effort is going to gain the momentum and perhaps get purchased by MSFT, ala Xamarin, but more UI-focused (as opposed to framework/tooling-focused, which is Xamarin's core strength IMO). So, something like Avalonia or Noesis, which offer their value proposition via open source and paid channels, respectively. Incidentally, both of these are built-on/support Mono.

[4creators]

Xaml Standard has moved a bit with release of XAML Standard (Preview) for Xamarin.Forms and long overdue update on project progress. There is a very interesting discussion in PR dotnet/designs#111 about project goals which seems to be going in direction benefiting this proposal

[badre429]

Silverilght is great solution the code already exist

1. Open source silverlight code
2. Makte it run on top of dotnet core runtime
3. use moonlight for linux distribution
4. create dotnet core alternative for "Electron" it willl eath the world (less memory usage + huge perf improvement+ xaml goodness)
5. native compliation (if one day corert project see the light)

[gulshan]

Found it relevant- http://platform.uno

[vibeeshan025]

@gulshan Interesting, Great project, Is it supporting most of the UWP feature, How they were able to implement such a rich set of featears in a very small time with just 4 contributers.

[galvesribeiro]

@vibeeshan025 they have a company funding it IIRC...

[gulshan]

Another future worth exploring- HTML/CSS + .net(instead of JS/TS). Already being tried here-
https://github.com/SteveSandersonMS/BlazorElectronExperiment.Sample

[CatGirlsAreLife]

After researching it seems tcl/tk could be a gui option for all platforms. Not sure if tcl/tk when on Windows invokes the actual gdiplus stuff but it might be a option to bring WPF and Winforms to Linux, Mac, Windows, Android?, iOS?, And maybe webforms? Not sure if tcl/tk supports those 3 last ones yet. If it does this makes the GUI hell much easier to maintain with a single code base on it.

Possible GUI libs to use:

• TclBridge (does not seem to be free or open source)
• the Mono one (probably the best maybe)
• Eagle (not sure how good it is)
• Maybe others as well.

I got the idea of using tcl/tk from cpython's tkinner module.

Also not sure if .NET Core supports loading resources from *.resources(compiled resx) or even from *.resx yet. If it does it would be great.

[4creators]

Microsoft.DesktopUI.App currently v3.0.0-alpha-26921-3 is available with daily builds of Windows .NET Core SDK. I am curious what would be needed to get it up and running on Linux under some translation layers for GDC and DirectX.

[Bartolomeus-649]

It need to much more than cross platform UX, it need to be a cross platform application development framework.
To limit it to only the UX is a mistake. It should at the very least have all the functionality of SilverLight + RIA-Services.
When you write huge custom systems for larger companies that will live on for decades, you need to keep all options open since you have no clue what requirements will be added in a year (or in 10 years), so a closed down and limited environment like UWP will never be considered, the same with something running inside a browser. There has to be full, unlimited and native access to every single feature, API and service on the different platforms.
And when you develop a system where you write both the server and the client, then you don't want to use REST or something like that (which is intended to be used when you write the server, and someone else writes the client), instead it should be in the spirit of RIA, where you define the server API and then automatically just call it form the client using the same (===) classes and methods as those on the server. Everything need to be strongly typed. Data validation starts with the hard limits obtained from fields in the SQL server (or whatever data source you are using), and extended by DataAnnotations, which are propagated all the way to the client automatically (taking localization into account).

This is what is needed, nothing less is acceptable:
Create a Ubiquitous .NET Client Application Development Model

It is now 20 years since Visual Basic 6 was released, and we are nowhere close to the productivity we had then in 1998.
Microsoft need to present their vision on how a larger custom system should be done in a "Microsoft world", and how they will bring back the productivity we had 20 years ago.

Microsoft need to get their shit together and step up and accept the responsibility they have. Microsoft need to realize that all their customers, partners and developers that has invested heavily in MS technology for decades are deeply disappointed and their trust in MS is very low. MS need to start respecting their customers, partners and developers and rebuild their reputation and respect, but seeing what they now are doing with Skype and how they treat their Skype customers and users, I have little hope this will happen.

And forget about Xamarin, Microsoft don't even use it themselves, and rather go for a single threaded memory-hogging framework like ElectronJS framework (based on Chromium, Node.js, JavaScript and CSS), than use Xamarin, which they own and have full control over, and which would produce real native code for each platform.

[dasMulli]

@Bartolomeus-649

It is now 20 years since Visual Basic 6 was released, and we are nowhere close to the productivity we had then in 1998.

And the spread of computer and internet usage as well as the diversity of platforms (OS / mobility / form factors) is nowhere near as low as in 1998.

What I feel you are asking is for "someone to solve all your problems". The reasons this diversity exists are multiple, or we we would all be using the same device with the same operating system. Building an "abstraction over everything" is hard and usually only gives you the smallest possible feature set. Xamarin has still the best approach here, allowing you to use platform-specific APIs where possible. But even good abstractions for mobile applications may not help you for high productivity desktop applications.

On the other points you are making, I think those are mostly personal opinions or observations that apply to your specific work and not generally applicable statements.

I do hope we will get better cross-platform experiences, but I don't think that it is going to be easy or will stand the test of time. Even if WebAssembly and Electron-like shells, PWAs and friends evolve to the go-to solution in the next 5 years, we may be doing something completely different in 20 years (and then we'd complain about how easy things were in 2018 😂).

[4creators]

Microsoft has lived up to our expectations and open sourced UX frameworks. We can now start community projects to port them to other platforms. Unfortunately, MSFT has explicitly stated that they do not plan to work on any ports so it seems this job is left to community.

@richlander @karelz @AdamYoblick @llongley @kmahone

My question is if we - community could work on Linux and macOS ports within existing repos i.e. in separate branches or should we create separate repos to support such projects? This is very important decision as using existing repos would allow us to integrate ports with MSFT CI infrastructure which otherwise would have to be setup from scratch by community.

[Happypig375]

Is there a reason why Xamarin.Forms/Avalonia/Platform.Uno don't suit your needs? It seems that a new attempt at bringing cross-platform XAML brings little value to the community as a whole.

[PathogenDavid]

Not 4creators, but my 2¢/impressions:

• Xamarin.Forms seems to mostly focus on mobile scenarios.
• Same for Platform.Uno
• Avalonia isn't ready for prime time yet. Too buggy for me to want to trust it. (Last time I went to check up on it, the demo app wouldn't even build in the current stable release, doesn't exactly inspire confidence.)

I'm not saying a cross-platform port of WPF or Winforms is the solution here. (An API-compatible cross-platform port of Winforms isn't even a great idea in the first place, IMO. No comment on WPF.) However, I don't think the existing solutions are suitable for desktop application development either.

[Happypig375]

Good points. Still, we should focus on improving existing solutions instead of building another one, which costs a lot more than the former.

By the way, any pain points about NoesisGUI?

[jkotas]

community could work on Linux and macOS ports

@4creators Create forks that you own and have full control over.

CI infrastructure

.NET Core CI infrastructure is moving towards using a regular Azure DevOps instead of the current custom Jenkins-based solution. Azure DevOps has free offering for open source projects that you can leverage.

[AdamYoblick]

Speaking only for dotnet/winforms:

Winforms is using AzureDevOps already, and any PR into master will run the PR CI build automatically.

However, I'm pretty sure any work has to be done in a fork. We're not planning on granting write access to dotnet/winforms just so people can create their own branches. With all the public contributions, that would pollute our repo quite a bit. :)

[PathogenDavid]

By the way, any pain points about NoesisGUI?

Somehow NeosisGUI was spared from my notes I keep on various UI frameworks, so I had to look at it again.

I've not used it, although I've been meaning to try it. My impression is it's meant for supporting in-game UI, so it might not be suitable for tools. (Although looking at the controls listing, this might be a bad assumption.) For in-game UI, our needs don't justify the future cost. It also doesn't support the Nintendo Switch for whatever reason. (Although apparently it's a work in progress.)

[charlesroddie]

@4creators I think this issue is mis-titled, because of confusion of two issues.

First, allowing .Net UI frameworks to use .Net Core instead of other .Net runtimes. WPF can run on .Net Core now, and they could make Xamarin.iOS/Android/Mac/GTK run on .Net Core too. This has performance and maintenance benefits compared to using Mono or .Net Framework.

However doing does not create a new cross-platform UI framework. And the threads you reference and most posts here are about creating a new cross-platform UI framework. The runtime is not the main issue here. These threads are extremely confused however because they don't address the actual difficulties of implementing cross-platform UI, which actual implementations (Xamarin.Forms largely using native controls, and Avalonia using common rendering) have addressed.

It's better to work on improving Xamarin.Forms desktop capabilities by adding the relevant desktop controls (not hard), or contribute to making Avalonia stable if you prefer. Any new platform (even if it's based on an existing single-platform one) will take years of work to get to alpha quality, and the only justification for redoing Xamarin.Forms & Avalonia rather than contributing to them is that they are both doing it wrong.

[Happypig375]

I agree on the latter part. However, the Xamarin team have explicitly said that replacing Mono with .NET Core is infeasible as they are optimized for different workloads and significant nontrivial integration work will need to be done.

[4creators]

I think this issue is mis-titled, because of confusion of two issues.

@charlesroddie IMO, not really. The point is not to have some UX framework available on .NET Core platform but rather The UX which is a part of the DotNet ecosystem created and maintained jointly with other parts. MSFT future plans for .NET ecosystem are .NET Core based with .NET Framework deprecated to being legacy Windows component not recommended for new application development. There are currently no plans to port Xamarin.Forms to .NET Core with some reasons indicated above by @Happypig375 and the the other reason being a lack of decision of how to proceed with xplat support on mobile. However, I do assume that due to the development effort invested in .NET Core the future xplat platform used by MSFT will be .NET Core based.

Mono is not optimized enough for many workloads even on Linux and there are no major new features developed on top of that runtime anymore. BCL is currently shared between Mono and .NET Core. This points to high probability of Mono deprecation in future.

Based on this assumptions I do think it is worth to have a single UX platform based on .NET Core as part of its ecosystem. Therefore, issue title is exactly as it should be since I do not ask for some UX framework which is xplat and based CLI standard but for UX framework which is part of .NET Core ecosystem designed and supported by DotNet team.

[charlesroddie]

.Net Standard ensures that UI different runtimes can be part of the same ecosystem with no problems. Although .Net Core has advantages over other runtimes, which may eventually be depreciated, it's not necessary to link the runtime with finding the right approach to cross-platform ui. It just overcomplicates the question.

It's going too far to say that a UX platform is "based on" a particular runtime. @Happypig375 It's not currently in Xamarin's plans to switch to .Net Core (the plans being instead to let Mono become more similar to .Net Core by sharing code). But it should be no harder than moving WPF to .Net Core.

(BTW, it's not true that Mono has no new features as it is being updated to support .Net Standard 2.1, and current work on webassembly is being done in Mono rather than .Net Core. But that's an aside as this work can be ported to .Net Core.)

[4creators]

WinUI 3.0 roadmap - we need your input!

It seems that this development proposal could open new xplat possibilities once all required components are open sourced.

[Mike-E-angelo]

They should consider calling it MicrosoftUI 1.0 if that is the case, @4creators. 😆

[dragmz]

> * https://github.com/Microsoft/microsoft-ui-xam
-------------------------------------------------^ missing l

[terrajobst]

I believe this issue is addressed by this repo.