I suggest you ...

Create a Ubiquitous .NET Client Application Development Model

This suggestion is migrated to Developer Community. Please use below link to view the current status.
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!

11,267 votes
Sign in
or sign in with
  • facebook
  • google
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Developers Win! shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


    Sign in
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      • Rod commented  ·   ·  Flag as inappropriate

        I agree - is time to start pushing MS tech to the rest of the boys

      • Anonymous commented  ·   ·  Flag as inappropriate

        i dont care about all the web technology stuff.

        but i would love an updated silverlight runtime that allows me to run uwp apps on a mac and under ios!!

      • Developers Win! commented  ·   ·  Flag as inappropriate

        Hi Erich, thank you for the link. As you probably know, Xamarin doesn't allow for transpilation to HTML5/JavaScript/web artifacts, which is a fundamental ask for this idea/suggestion. As it stands, JavaScript and .NET are two incompatible languages, and developers/organizations are switching to nodejs as they can share code (saving money and time) between server and client for both web-hosted and native (via Cordova) development.

        This simply is not possible with .NET at the moment, which is what this idea/suggestion is precisely about. Your support around this idea is greatly appreciated! Thank you for the continued dialogue and thoughts.

      • Mike-EEE commented  ·   ·  Flag as inappropriate

        @Aaron, well, with THAT attitude. Remind me not to put you in charge of any projects or applications that I need built. ;)

        I am not sure if you fully understand the ask/idea here, so I will try to attend your points one by one.
        1) when you say time and money "developing other things" -- this is exactly what is happening now in a very large scale with developers and organizations as a whole. Since technologies are fragmented and there is no consistent model that spans all known platforms that these technologies address, organizations and developers are spending their time between fragmented between these different technologies. Because of this, developers (.NET in particular) are becoming generalists in these different technologies rather than experts in one. More on this here: http://blog.developers.win/2015/12/is-net-in-trouble-belated-thoughts-from-connect-2015/
        2) When you say "new feature" I will need more context. To be sure, a great majority of required language "features" and platform capabilities are already present across the board. That is, from a .NET perspective, you can take any given feature and find its adaptive equivalent in any target platform. Xamarin and JSIL have proven this out and show there is no technical barrier from making this possible. You will need to provide a working example here to discuss further.
        3) A working example would be nice to know here, too. The capabilities are there, and there is no known technical barrier to keep this idea from happening. The existing barriers are political will and time.
        4) Here we are running into a systemic and pervasive misunderstanding of what a "web app" is and how it should be viewed. To be more accurate, a "web app" is simply a client application that is hosted within a web context. There is nothing conceptually different between a client application hosted on a server and one hosted on the local machine. However, we have had some pretty poor conceptions reinforced around this notion of what makes a "web app" compared to any other client application. We as a developer community as a whole have always thought of "web sites" as a different animal, but really they are indeed client applications and should be viewed as such. They are conceptually and semantically the same thing, but simply comprised and traditionally built in a different fashion from how other client applications are built. Web-hosted technologies have finally reached parity with native technologies and we are finally on a different playing field than what we have had in the past.

        As for Java for Gui... I am not sure that there has ever been a cross platform compilation/transpilation for this technology? From what I understand it was based on VM/plugin/installs (to this day even, annoying) so that is not the same idea/approach as this idea.

        Finally, I would like to point out that you suggest developers should continually reinvent themselves and the technologies that they work with, and this idea/suggestion does exactly that. ;)

        .NET is a major MSFT investment (probably the greatest/biggest?), and it should be protected as such. Thank you for your continued feedback, discussion, and support towards this idea.

      • Aaron Lawrence commented  ·   ·  Flag as inappropriate

        And a pony too?
        This is a nice wishlist, but it's extremely unlikely to happen, because
        - it would cost very large amounts of money and time (which would take away from developing other things)
        - such a model will always be "behind" in time compared to native implementations e.g. a new feature arrives on platform X, and the tool takes a year or so to start supporting it, or never supports it because it isn't common to other platforms.
        - it will always produce a lowest common denominator, that is a poor cousin on most platforms
        - especially, producing a "web app" by this means would produce something very unlike other native web apps

        It's clear that it would be nice for developers who have already spent time on existing technologies, but as always, the world moves on and you have to reinvent yourself continually.

        Such things have been tried in the past - Java for GUI apps as an example - and invariably fall behind.

      • Developers Win! commented  ·   ·  Flag as inappropriate

        @Vili, indeed. Every attempt has been made at ensuring ".NET" and not "C#" has been said throughout the posted series and in the posted idea here, so F# (and any .NET existing language) support is indeed assumed and expected wherever C# is within this idea/suggestion. To be sure, code is expected to be written in .NET (C#/F#/VB.NET) and then transpiled into JavaScript seamlessly when needed for either debugging/development and/or deployment, and for on-demand for intensive computation as you are suggesting. This of course makes the most sense for web-hosted scenarios, as native/store-hosted scenarios would have the .NET code compiled into the native bytecode as applicable.

        Thank you for pointing that out... and for your support!

      • Vili Volčini commented  ·   ·  Flag as inappropriate

        (F# -> Javascript compiler) on the fly would be awesome. Imagine offloading computation/code from server to client just with simple call :).

      • Developers Win! commented  ·   ·  Flag as inappropriate

        @mala, thank you for sharing Eder's vote. It is great to see this idea and the idea you reference sitting at #1 and #2 hottest ideas in Visual Studio right now, respectively. Also, this idea crossed the 1,000 mark today, and that is nothing short of awesome and beyond any expectations when this vote was initially created short of 8 weeks ago. Combined with the related votes over in UWP's board, the demand for a ubiquitous .NET client application model is over 3,500 combined votes between the voting boards (you can view the weekly vote reports at the referenced link below in a previous comment).

        The support really has been amazing. A tremendous thank you goes out to all who have supported so far. This is far from done, however. A look at the top votes here @ Visual Studio board shows there are ideas with tens of thousands of votes rotting on the vine or "under review" with months (or years!) of time passed without an update. That should scare anyone wishing to make a vote on this board or who has hopes of having their idea heard here.

        By contrast, hopefully these two votes will start to generate some internal discussion there at MSFT and get some seriously disruptive, marketplace-dominating innovation going on again in the MSFT client application development space.

      • mala commented  ·   ·  Flag as inappropriate

        If anyone is interested, we are keeping track of this vote and others like it at


        Bring Windows 10 Universal Apps to Android and iOS

        Create something like what Xamarin is doing in order to help developers to code once and run EVERYWHERE (Wndows 10, windows 10 mobile, android and ios).

        If Microsoft could not buy Xamarin, at least do what they are doing by your own. Make something that enable us to archive real NATIVE cross platform development. It could dramatically increase the numbers of developers using .net to create mobile applications as well as increasing the number of apps created to wp too, since app could be compiled to ios, android AND WINDOWS PHONE. Hibrid apps like apache Cordova has a lot of potential but right now it is limited to offer a bad user experience when compared to the native apps you could build native with native objective-c on iOS, java on Android or C# (on Xamarin.Forms o WP and Windows 8). Porting .net to others platforms is good, but go further MS, create something that help us to "code once and run everywhere. And by EVERYWHERE I mean, not just windows, I mean: Native apps on Android, iOS, Windows PC, Windows Mobile, Xbox, HoloLens and to on. Bring us a tool that enable us to make Visual Studio Universal Apps REALLY UNIVERSAL (running as well on android and iOS).

        We want a Framework that enable us to build NATIVE.
        By the way Xamarin Starter edition has a very limited package size so is almost impossible to create even small apps with an organised architecture (multi layers) and its licences fees is very expensive too.
        Hey M$ look to the opportunity a tool like Xamarin could bring to the windows ecosystem. It could help you to resolve the app gap Windows Phone suffers so far. With a tool that can help developers to build native applications to windows as well as to android and iOS could bring the apple and android developers interest to use it and since it will be able to compile to windows phone then they will not have why to do not do so. It will also bring mobile developers form other platforms (android and iOS) to Visual Studio and .NET.

      • Darksworm commented  ·   ·  Flag as inappropriate

        "continuing like this, the new versions of .Net will even exclude more of MS own OS's, and these operating systems are still used by the majority"

        And developers will continue to target lower versions of the .NET Framework from Visual Studio to accommodate users on those OSes, which kind of defeats the purpose.

        Even Visual Studio 2015 defaults to targeting .NET 4.5.x by default, instead of 4.6, for example.

        Honestly, I feel like .NET has introduced more headaches than benefits to client application developers. The performance delta between different UI technologies from Microsoft is far beyond trivial, and WPF performs terribly on lower/mid-range machines which are a ton of Windows' users. Hardly anyone wants to deal with MFC for new projects, and we lost VB for Quick Data-Based Projects.

        On top of that, Microsoft is deprecating technologies like SQL Server Compact and making it a PITA for some of us who develop solutions for our own use using them. I'm back to using Access for the moment. I don't feel like a 150MB (300MB+ Install) Payload is worth any of SQL Server Express LocalDB's benefits... Never mind that is a hard sell for people selling apps that used those technologies, should they migrate to Microsoft's "replacements."

        Eventually, I will stop using Windows for my personal stuff and migrate all of that over to OS X/Cocoa. Things are a lot more organized in Mac-Land.

      • Developers Win! commented  ·   ·  Flag as inappropriate

        @Marc Roussel, indeed,that is a piece of the puzzle. :) CSHTML5 satisfies a good number of the desired qualities of a ubiquitous .NET client application model. Primarily, it takes the desired and ultimately logical approach of transpiling .NET into HTML5-compliant artifacts. Unfortunately, it doesn't account for such critical features such as Portable Class Libraries or support shared/common assemblies for code reuse between application/server boundaries (cross-boundary accessibility). It also doesn't support a native-compiled workflow for store-hosted/native applications (more performant than JS). Nonetheless, it is on the right path and ultimately offers a more cost-effective approach/design than what we saw endorsed on stage by MSFT during Connect 2015 (traditional JS front-end on a .NET backend -- great for node.js, terrible for .NET).

        You can see more about CSHTML5's (and other models') alignment with the desired qualities here: http://blog.developers.win/2015/10/existing-net-client-application-models/#cshtml5

        Thank you for your support!

      • Developers Win! commented  ·   ·  Flag as inappropriate

        Thank you for your feedback, Maxwell. Self-hosting ASP.NET has actually been in discussion:

        The problem with this approach is that JS on the client and .NET on the backend are incompatible (cannot share code across boundaries), and therefore break DRY. More details here:

        As you mention, nodejs works really well in this scenario, as JS can be shared between client and server boundaries, reducing development time (and therefore, cost). This is why developers and organizations are moving away from .NET and a solution like this idea suggests is necessary.

        This is all unless, of course, you mean bundle a browser that renders *transpiled .NET code as JavaScript* then of course that makes perfect sense. :)

      • Developers Win! commented  ·   ·  Flag as inappropriate

        If anyone is interested, we are keeping track of this vote and others like it that aim for a ubiquitous .NET client application model. The first report can be found here:

        Future weekly reports will be found here:

        As of today, the ubiquitous .NET client category has just over 3000 combined votes at 3013. Not bad. :) Please continue sharing this idea and make sure that our voices are heard!

      • yuliya alasheeva commented  ·   ·  Flag as inappropriate

        Украли мою разработку, я на Facebook отправляла ссылку, потом удалила.

      • reader commented  ·   ·  Flag as inappropriate

        Man, MS reached to a point that even it's own old OS's are left behind, the new .Net 4.6 system requirements:
        , does not support windows XP, and all Windows Server from 2012 and bellow.

        continuing like this, the new versions of .Net will even exclude more of MS own OS's, and these operating systems are still used by the majority.

        and I did not start talking about other OS's from other vendors, and as some of us recall, when MS talked about creation of .Net
        , it was to fight java moto:

        "Write once, run anywhere" (WORA): https://en.wikipedia.org/wiki/Write_once,_run_anywhere

        , while this succeeded in java to a certain point, it was forgotten by MS. Totally!!

      • Mike-EEE commented  ·   ·  Flag as inappropriate

        Thanks for the dialogue, developers... this is awesome. :)

        @Louis, that migration path is unfortunately one of a broken, incompatible system as highlighted by the series. It is transitioning into a sub-optimal and inferior design from a .NET perspective. Again this works great for JS-only solutions, but not so for .NET-backed ones. :(

        @stimpy77: this goes beyond Windows 10 and is for .NET client application developers. The bridges you speak of are going into Windows, not out of, which is backwards and what the series and this vision seeks to address. Even at 1B Windows 10 installs, there will still be ~1.5B installs of Droid/iOS that outweigh Windows 10, and even much more ubiquity found in the web:

        @Marc: To be sure, the transpilers/compilers only come into play when you are ready to deploy to a target environment/platform. Until then you should be able to develop as you suggest: freely and quickly with instant feedback. And yes, I am dreaming out loud right with you, LOL!

      Feedback and Knowledge Base