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)
      • Louis commented  ·   ·  Flag as inappropriate

        I have read http://blog.developers.win/2015/10/the-broken-burned-bridge/ and I am convinced that MSFT alone is unable to set a programming standard as .Net anymore. The billions of future devices will only work based on standards and .Net is not a part of that standard. At the moment Javascript/ECMAScript2015 is such a standard, whether you like it or not. HTML5 is such a standard, and with Web Components comparable with XAML. I was a VB and .Net addict and I tell you that Javascript/Typescript is a strong alternative.

      • Mike-EEE commented  ·   ·  Flag as inappropriate

        @Louis, using TypeScript (or traditional JavaScript) within a .NET solution introduces the problem discussed at length here:


        Conversely, what this solution aims for is a .NET (C#/VB.NET/F#/etc) transpiler to JavaScript artifacts.

        However, we're all about and open to the idea and prospect of XAML-to-HTML5 transpilation as well. :)

      • Terry Murray commented  ·   ·  Flag as inappropriate

        This is quite obviously the largest obstacle to .net adoption. C# is beautiful, and can quite easily be the most popular language in the world. If Microsoft wants usage growth, we need CLR ubiquity. Start picking platforms and making it happen. At the very least shell out the process and let the community do the work.

      • Developers Win! commented  ·   ·  Flag as inappropriate

        Good questions/points, David. There is no doubt progress being made (especially when compared to 5 years ago), but it is not as focused/clear as it could be. That is part of the vision/ask of this vote: to make a clear, innovative push that truly creates a powerful, authoritative .NET client application model for its developers.

        Roslyn is being used by Duoco.de for their transpiled solution. However, it doesn't account for PCLs (Portable Class Library) and other technical challenges. Mono does indeed support the platforms you mention, but not the web. For an idea of how this is important/significant, please see the following chart that demonstrates HTML5's ubiquity when compared against platforms (all figures guesstimated based on current Net Market Share data and MSFT's target goal of 1B Windows 10 installs by 2018):

        Additionally (and more importantly from a business-perspective), MSFT is losing revenues to web developers as they are charging developers to access the Windows Store. Every web developer is another $19/$99 (developer/company) lost from a Windows Store perspective (not to mention fragmenting the .NET ecosystem even more between incompatible HTML5 and .NET client models).

        All the pieces are there for an innovative, powerful solution that preserves/strengthens .NET/MSFT brand and IP, all the while featuring a legitimate business to drive revenue for shareholders. It's just a matter of tying up all the pieces and making it work, while also generating some bucks for MSFT (as opposed to bleeding it via web developer attrition, as is the case now).

      • David Thole commented  ·   ·  Flag as inappropriate

        I'm a little unsure on this. When you look at the new .net rosyln project, doesn't that solve this issue, at least from a desktop standpoint? Also, mono has the ability to push code to android/ios. It's not perfectly seamless, but I think MS is going in the right direction on this.

      • Developers Win! commented  ·   ·  Flag as inappropriate

        Funny you should mention that, Koen. The original version of this vision/idea from over four years ago did account for BlackBerry: http://dotnetfuture.wufoo.com/forms/m1azjhyi1ozawho/

        In the current version/vision, that is denoted with the 8th and final item listing of "different, future platforms." Additionally, transpiled HTML5 client artifacts and packaging would satisfy this requirement as well.

      • Developers Win! commented  ·   ·  Flag as inappropriate

        Thanks Eder! Together our two votes are over 1000 already. :)

        There is also another one in Windows Developers here: https://wpdev.uservoice.com/forums/110705-dev-platform/suggestions/7989744-make-universal-windows-platform-open-source-and-cr

        And here: https://wpdev.uservoice.com/forums/110705-dev-platform/suggestions/7897380-expand-enable-universal-windows-platform-to-transp

        Combined all of these votes are over 2,000 in total at the moment. Hopefully MSFT does take the time to consider and hear our voices at some point. Good luck with your vote as well!

      • Eder commented  ·   ·  Flag as inappropriate

        I Just read your idea could not more than agree with it. at all.
        Congratulations. Hope Microsoft hear that a

      • Garry Lowther commented  ·   ·  Flag as inappropriate

        Having been left out in the cold after our investment in .Net when Microsoft released Windows RT - a version of windows which did not run .Net apps (or even win32 apps) at all, I seriously doubt that Microsoft would reverse their decisions. We, like many other ISV's, have been gradually re-architecting our .Net code base to target non-Microsoft platforms, so Microsoft should take note of this suggestion to try and stem the exodus.

      • Developers Win! commented  ·   ·  Flag as inappropriate

        Thanks for your comment, Raymond. It would be nice to know more about what you mean. To be sure, the proposed suggestion here is to JavaScript, rather than TypeScript. In much the same way that TypeScript compiles (or transpiles) into JavaScript, the suggested solution here is to compile (or transpile) .NET languages/resources (C#/VB.NET/F#) into JavaScript. JSIL.org (which CSHTML5 -- a product that is referenced in one of the comments of your vote -- is based on) has been at this for years, and really a case should be made that it should be focus of (at least) an entire group within MSFT. In this process, deliverables/artifacts are created when the application is compiled/transpiled and made ready for deployment. The server is never involved except for its role in hosting these deliverables/artifacts so that they are available to any HTML5-compliant browser that requests them for the purposes of loading and displaying/rendering to the end user.

      • shimmy commented  ·   ·  Flag as inappropriate

        Most important thing I would probably ever want from MS as soon as possible!

      • Mike commented  ·   ·  Flag as inappropriate

        Perhaps use WebGL as the rendering surface;... with asm.js as CIL

      1 2 21 22 23 25 Next →

      Feedback and Knowledge Base