I suggest you ...

Create a Ubiquitous .NET Client Application Development Model

This vote is for developers who wish to see the idea of a ubiquitous .NET client application development model created by Microsoft and the Visual Studio team.

A ubiquitous .NET client application development model is a model that is defined in .NET-based technologies and is able to run in a multitude of runtime environments -- both native-compiled (store-hosted) and web-hosted.

A *very* rough image of the vision can be found here:

The goal is to enable *one* .NET Client Application Project to build deliverables for the following platforms:
1) Windows 10
2) Legacy Windows
3) *nix (Unix/Linux)
4) Droid
5) iOS
6) Macintosh
7) HTML5
8) ??? (Extendible to different, future platforms)

In order to achieve the above, a ubiquitous .NET client application development model should strive to possess the following qualities:
1) Native Cross-Platform Capable - For native-compiled/store-hosted scenarios (iOS/Droid/Windows Store)
2) HTML5-Compliant - For web-hosted scenarios, via .NET-to-JavaScript transpilation
3) Consistent User Experience - For brand recognition, reinforcement, and optimal usability across all known scenarios
4) Cross-Boundary Accessibility - For shared code/assemblies between server and client boundaries
5) Xaml-Powered - Harnessing one of the greatest inventions in Microsoft's great history
6) Object Serialization Congruence - Markup used to describe serialized objects is what is created in memory
7) Holistic Development Consistency - The same guidelines and conventions are used in both client and server scenarios

For more information around this idea and the qualities above, a series of articles has been created to discuss the notion of a ubiquitous .NET client application development model at length. You can view that series here:

Finally, this is intended to be a starting point for discussion, and not a final solution. THAT is meant for the experts there at Microsoft. :) Thank you for any support, dialogue, and feedback around this idea!

7,436 votes
Sign in
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Developers Win!Developers Win! shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


    Sign in
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      • AnonymousAnonymous commented  ·   ·  Flag as inappropriate

        Currently there is :-
        1. Neosis and Ammy
        2. Avalonia UI

        The winner for me in regards to LOB will be whichever gets EF support and third part controls such as Telerik and Component One? Plus, WASM support thereafter.

      • Mike-EEEMike-EEE commented  ·   ·  Flag as inappropriate

        @Anonymous (and really, open an account here, LOL), I would say that both Avalonia and Noesis is greater than SL3.0. Avalonia has a lot of heart but it hasn't reached critical mass yet. It is still in alpha. TBH it is an extreme challenge to pull off a feat such as this in a closed-source capacity.

        I would say that Noesis is more like what UWP *should* be. It does lack markup extensions, but they just verified that they are on the way: https://twitter.com/noesisengine/status/837226399727378432

        If I were to start a project today I would definitely go with Noesis above any other option since it is now free for indie developers, has a team that cares about Xaml, listens to its customers, and doesn't take five years to implement features *ahem*UWP*ahem*.

        That is not to discredit Avalonia, but like I said they are in alpha currently vs. a 2.0 product. Again, the Avalonia team has a lot of heart and I will definitely be keeping track of their efforts.

        And yes, once you get vendors making controls for you, then you have arrived, indeed. :)

      • AnonymousAnonymous commented  ·   ·  Flag as inappropriate

        OK so

        1. Avalonia is SL 2.0 open source
        2. Neosis is potentially SL 3.0 with xaml support

        My feeling is that once one of these platforms gets Telerik, component one etc etc it'll be go to place for LOB apps.


      • birbilisbirbilis commented  ·   ·  Flag as inappropriate

        Nice news about Noesis, hope they make it free for opensource apps too (please correct me if it is already so)

        btw, have seen they've been working with Ammy dev to support that too - hadn't heard about that one, it's something like SASS for XAML but with {...} style syntax and various goodies - http://www.ammyui.com/ - read some are using it to allow end-users to create skins (without messing with the lower-level XAML details)

      • birbilisbirbilis commented  ·   ·  Flag as inappropriate

        Next Firefox version also disables all NPAPI plugins except Flash. Yeah, keep Flash with its security exploits, but not Silverlight. After all the Edge team led this silly race

      • AnoneeAnonee commented  ·   ·  Flag as inappropriate

        thanks, Mike EEE, I know that is .Net Std 2.0. I mean MS should unify the name for .net framework.

      • AnoneeAnonee commented  ·   ·  Flag as inappropriate

        Microsoft shoud discard mono after they acquired Xamarin, or at least merge Mono into .Net Core or .Net Framework, make just only ONE .net runtime/framework for every platforms (Windows classic , store app, ANdroid, Linux, MacOS...) They can have multipal implementation of .Net framework for different OSes, but from the developers point of view, they are all have the same BCL/API. for hardware/device specific APIs, I think this could be solved by additional Assemblies/Packages, such as iOS.dll, Android.dll.

      • Mike-EEEMike-EEE commented  ·   ·  Flag as inappropriate

        Far too sensible of an idea, Anonymous... it will never work. ;) But no, if you want to amass a coordinated community effort, why not focus all firepower on Avalonia?


        Just think: Avalonia uses Mono, and Mono is being ported to WebAssembly. It also already runs/supports the same platforms that Mono does as well. So when Mono finally supports WebAssembly, so will Avalonia (in theory).

        COOL RIGHT??? I just connected those dots. Surprised it took me that long. Avalonia is basically the free/open-source/community counterpart to Noesis.

        Also, "YES" to all of your understandings below. :)

      • AnonymousAnonymous commented  ·   ·  Flag as inappropriate

        So basically, we're saying :-

        1. Xamarin Forms isn't up to scratch for a LOB app.

        2. UWP is a bit pants.

        3. WPF / SL are still pretty good all things considered.

        Therefore, either MS or someone else needs to put WPF/ SL or improved UWP in WASM?

        As I think we could all be waiting indefinitely for MS to do this (because they appear to be silent on the matter) - should we create another forum for people to show their interest in picking up mono in some way with xaml or equivalent? Something that make it easy for third party control vendors to make controls for.

        Would be very nice to have something ready for when WASM matures. I think perhaps it would pull some devs away from the JS, Angular mess.


      • birbilisbirbilis commented  ·   ·  Flag as inappropriate

        btw, the native rendering approach of Xamarin.Forms is like that of Java's AWT which JMF/Swing tried to change (with a nicely designed but having bad [not natively feeling enough] native emulation L&Fs [Look and Feels / themes /skins] that gave it a bad name eventually).

        Another major issue was that you couldn't mix native and non-native (owner drawn in Swing) controls in the Z-order easily (you had to do various hacks with native code). Not sure what Xamarin.Forms does in that area

        Then later on came Eclipse with SWT to bring back the AWT approach. However, I don't see why I would need to do write-once-test-everywhere (and especially test with future platforms that aren't yet released) with the UI when I want to do write-once-run-anywhere (and especially release-once-run-anytime in the future).

        I'd like to control how my app shows and even define my app's visual identity to stand out. That's why there were libraries to do skinning for windows apps etc. It is nice to be able to use a native skin though without having to emulate it and I think that's what Xamarin tried to do with native renderers. One could probably have theme libs where all basic controls are rendered custom and the app and component authors could use just those controls (and define new via composition). Could also have some cross-platform theme(s) where those same controls are rendered via some cross-platform graphics primitives (XAML path etc.). So instead of having control authors provide native renderers for more speed, app authors could choose native (not emulated like Swing tried to do) themes for more speed. Don't know if SWT has such an approach, could be (haven't examined it much)

      • birbilisbirbilis commented  ·   ·  Flag as inappropriate

        From what I remember Xamarin.Forms doesn't require you to always build native renderers, think they also added a model later on where your control can render via the controls it combines (for composite controls), or draw via XAML-based primitives. Think Petzold had written some article showing that. Don't remember very well though

        As for Moonlight, think there was a beta or better version for Winter Olympics back then that had Silverlight 4 feature parity. A problem with Moonlight back then (according to Miguel that is now at Microsoft after Xamarin acquisition) was if I remember well that Microsoft had licensed them the use of the native codecs that SL included but only for usage within the browser (not for OOB [out-of-browser] style apps that the Windows Silverlight had I guess that meant) and obviously this model (of needing a closed source part and special licensing) didn't go well with opensource spirit. That was one of the good things with Silverlight btw, it came with cross-platform codecs in it (MP4/WMV video, MP3/WMA audio) so you didn't have to worry about what codec-**** the client had installed

      • Mike-EEEMike-EEE commented  ·   ·  Flag as inappropriate

        @Philippe I am with you 100% on everything but Xaml referring to UI engines. It is often conflated with UI -- and understandably so as it started out embedded in WPF -- but Xaml by itself evolved into its own assembly and is used for more than UI (Windows Workflow). Feel free to join the discussion here if you haven't already to port System.Xaml to .NET Core:

        And yeah, Xamarin Forms was a gallant attempt, but it should be shelved ASAP. When I said "combine" w/ UWP I was specifically referring to XF's Xaml system, which is better than UWP's but not as good as WPF's of course. In an ideal world we would want WPF's client model wholesale and replace both XF and UWP, for sure. :)

      • Philippe MonteilPhilippe Monteil commented  ·   ·  Flag as inappropriate

        Xamarin.Form and UWP cannot be compared: X.F is a layer on top of existing UI engines (iOS/Android/UWP, soon OSX) providing a valuable level of abstraction. UWP is a vector-based UI engine on its own.
        XAML does not only refer to the serizalization mechanism, but also to the various underlying UI engines.
        The MS models which should be combined, or at least built on strictly the same fondation, are UWP and WPF. The fragmentation imposed by WPF, UWP and in the past by SilverLight, SL fo Windows Mobile ... is absurd to say it politely.
        IMO, this fondation should be open-sourced, designed to be available to the .Net and non .Net langages, ported to WASM, iOS, Android, OSX, XBox, connected to Unity, Unreal Engine, ..., incidently removing the need for Xamarin.Forms.

      • Mike-EEEMike-EEE commented  ·   ·  Flag as inappropriate

        Correct @Anonymous. The Mono support is simply the ability to run .NET in a WASM host. There is no API that would be used to provide a client UI/GUI within that host at present. Currently there are two known MSFT models that could (and should) be combined (taking the best out of each offering): Xamarin.Forms and UWP.

        Unfortunately (or fortunately, depending on your perspective), WASM exposes a fatal flaw in Xamarin.Forms design. Namely, if you build custom controls, you are required to build a renderer for every platform that is supported by Xamarin.Forms. So if XF adds WASM, that means every control vendor must go through every control and release a new renderer for WASM.

        Very much a pain.

        Obviously, a model such as WPF/Avalonia is preferred where you have one model and your controls are skinned/themed according to the host it is rendering in.

        As for Moonlight, that might be a possibility. It's last known supported featureset is/was SL3, which if you know anything about was nothing compared to SL5. I would rather see a new effort altogether that is community driven like .NETCore/GitHub initiative. Like I said earlier the earliest we'll see anything is 2018.

      • AnonymousAnonymous commented  ·   ·  Flag as inappropriate


        Based on mono support for WASM. Would it be correct that there is no xaml GUI in mono?

        Only moonlight that didn't make it to full SL4?

        Why wouldn't the interested people on this forum pick up moonlight for development?

        Surely, it would be relatively easy for third party controls vendors to port controls to moonlight.

        If Moonlight supported SL + .net standard etc. would there be anything superior out there for WASM?

      Feedback and Knowledge Base