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,715 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)
      • Marc RousselMarc Roussel commented  ·   ·  Flag as inappropriate

        @birbilis interesting information you have there. I just hope one thing. I can take the $760 357.32 app I did for a customer and just run it against a new technology and not explaining to my customer I have to rewrite it.

      • birbilisbirbilis commented  ·   ·  Flag as inappropriate


        > MS should give us clear plan/roadmap for .Net/XAMl, but they don't.

        they do have .NET Standard coming which is very useful, seem to be gradually waking up about the value of more standard / portable XAML with markup extensions etc. like in WPF

        > Microsoft abandon lots of technologies, Foxbase, J++, Windows Mobile, Windows Phone 7/8/8.1, Window RT, Silverlight, BizTalk....

        J++ had issues with Sun's policy on Java (see long time battle with Google on Android for example). I liked the J# concept (.NET managed language - was even Microsoft MVP for it for several years), pity they didn't opensource it. Needed work to keep up with newer .NET releases, although the Dynamic Language Runtime (DLR) could help to reimplement it. Would be useful for people wanting to reuse Java libraries in .NET without porting them to C# or using interfacing technology and two different IDEs (say VS and Eclipse or NetBeans).

        Windows Phone Silverlight layer still exists in Windows Phone 10 and one can keep on using it in their app (with some timing glitches that I've seen in my small game [Amnesia of Who], though they may be caused though by specific hardware, not by the SL layer)

        Windows Mobile was Windows CE (Microsoft's official realtime OS offering), still used along with Windows Embedded. Concepts from it (modularization) have gone into recent Windows I think (there's even a Nano server for example)

        WinRT is the ancestor of UWP concept (and also see Windows on ARM where Win32 emulation is coming to next gen Qualcomm processors)

        Abandoning Silverlight was quite a silly move - Probably they were afraid of another silly EU action that was being prepared at that time against them for trying to kill HTML via XAML (yep, those EU sillies that also forced us to click those "cookie consent" dialogs all the time, especially if we use cookie cleaning [since sites don't remember we consent #LOL])
        They kept Flash in Edge and so does Mozilla now - if only they had kept Silverlight as embedded engine too in Edge (after all it doesn't have the bad record of Flash in security issues).
        Also they still haven't released from what I know Desktop Bridge support for wrapping up Silverlight OOB (out of browser) apps and publishing them to Windows Store, although it should be easy for them to do (could even make the Store accept upload of Silverlight XAPs marked with OOB flag and rewrap them online as Bridge-based apps for the desktop store)

        btw, according to https://en.wikipedia.org/wiki/Microsoft_BizTalk_Server there's a BizTalk Server 2016

        > Bill Gates has an ambitious plan to write whole Windows with C# at the begging of year 2000.

        at some point they were writing UI parts in HTML/JavaScript, but now with UWP they probably write them in XAML (the UWP flavor) and C++ or even C# (note that UWP [at least as used in Windows Store] uses .NET native when you talk to it from C#/VB.net/etc., not the .NET Runtime) and they constantly update the UI via product-as-a-service concept via the store. Or at least most of the UI

      • AnonymousAnonymous commented  ·   ·  Flag as inappropriate

        The larger forces like Apple, google, ms all try to create a walled garden.

        Let's stop hoping for a universal standard from one of the larger players and get behind Avalonia and Neosis.

        Innovation will come from smaller more agile software houses.

        I for one am prepared to port all our apps to Neosis should it get Telerik controls support.

        As developers we have one goal a single platform to write code without a mess of Libs.

        MS have too much red tape to even get close to the above. If Neosis have large apps running well then MS will most likely buy Neosis as they did Xamarin.

        @Mike-EE great work on pushing Neosis for third party controls support. Perhaps you could create a forum for companies to show interest in using Neosis to port WPF, SL and UWP apps. I'm positive that this would not only inspire Neosis to push harder, but would also help them raise funding and support from the likes of Telerik.

      • AnoneeAnonee commented  ·   ·  Flag as inappropriate

        @Mike-EE, thanks.

        Indeed, MS should give us clear plan/roadmap for .Net/XAMl, but they don't.
        Microsoft abandon lots of technologies, Foxbase, J++, Windows Mobile, Windows Phone 7/8/8.1, Window RT, Silverlight, BizTalk.... They do not have clear strategy, and changes frequently.
        If my memory is good, Bill Gates has an ambitious plan to write whole Windows with C# at the begging of year 2000.

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

      Feedback and Knowledge Base