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!

6,706 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)
      • Mike-EEEMike-EEE commented  ·   ·  Flag as inappropriate

        @Anonee, patience. :)

        I share your angst about the amount of time that this idea has been Under Review. In fact there is part of me that still says it was done by mistake. But make no mistake MSFT is investing into .NET. They wouldn't have acquired Xamarin otherwise. And it is that same Xamarin team that is porting .NET (Mono) to WebAssembly that would essentially actualize and complete this idea, so do not go rushing over to JavaScript unless you truly find it a better paradigm.

        FWIW, some kid genius back in 2011 made a transpiled .NET JS framework that already renders .NET in WebGL: http://jsil.org Now, how awesome would it have been to hear Steven Sinofsky jump up and down on stage at Mix'11 about THAT rather than trying to impress SL developers with blinking sprites in an HTML5 page?

        (Also FWIW, the reason why this isn't a viable option at present is that it doesn't support PCLs, so you still end up with multiple codebases)

        In any case, MSFT is running a business, and JS has indeed become ubiquitous alongside .NET. You can run JS everywhere, and it would not be very pragmatic for MSFT to ignore the market that has been created around this.

        Fortunately, with the advent of WASM and its Mono port, .NET will attain market reach parity with JS. And even technically speaking, other technology stacks such as Java should be along for the ride, too. As a result, we *should* (as this is all conjecture and based on my limited understanding) and will be able to select the technology stack that makes the most sense (and cents) to us, rather than the one (or ones) that can reach the greatest market. It's going to be a little longer yet, but it appears to be on its way. Stay tuned.

      • AnoneeAnonee commented  ·   ·  Flag as inappropriate

        May MS do not really want C#/XAML to be cross-platform, this suggestion has marked as "UNDER REVIEW" more than a year ago, and still have no more message from MS.

      • AnoneeAnonee commented  ·   ·  Flag as inappropriate

        What we need is a universal framework, that write code once, run everywhere.

        And I'm thinking if we get the wrong direction? Or, should we discard C#, and embrace JavaScript?
        JavaScript grows quickly in recent years, from server side (Node.js) to web front ( Js in web browser), and mobile development (reactive native, Cordova, WinJS), almost can do everything.
        And with webGL/Html5 Canvas, there's a lot of new Library that can build Windowing system in web browser (see links below), that is , cross-platform UI system could be build with JS at the same time.

        So, it looks Js has more brilliant future than .Net language (C#/VB/F#)?
        (Don't get me wrong, I personally love C# much more than JS.)

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

        @Anonymous, technically once .NET Standard is available, both Noesis and Avalonia will be able to utilize .NET (and EF) Core and deploy to supported platforms via Mono. As for vendor controls, I am actually discussing this with the Noesis team if you would like to follow along here:

        Now onto our regular Friday morning scheduling:

        Weekly Friday morning check-in: 59 votes were cast for this idea last week, bringing the total to 45,364 combined votes across 10 similar ideas asking for a ubiquitous .NET. Please feel free to like and/or retweet to show your support to the "Big Three" here:

        Thank you all who have shown and continue to show your support!

      • 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

      Feedback and Knowledge Base