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!

8,227 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! 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)
      • Anonymous commented  ·   ·  Flag as inappropriate

        Don't forget all the Winforms program that are out there. So View.Designer.cs to xaml (or similar) will need to be part of this. I wholly support a uniform Microsoft UI that can work across web and any device.

      • Aaron Huang commented  ·   ·  Flag as inappropriate

        The good news is the number of this vote is growing quickly, the bad news is Microsoft did not give any direct answer yet, except mark it as "UNDER REVIEW".

        @shimmy, No, Xamarin is far from perfect, there's a lot of work need to do. At first the Xamarin Forms still has a lot a feature/component/API missing (compared to WPF XAML), Second is the XAMLs for WPF/UWP/Xamarin is not compatible, the UI language is fragmented, I believe what we need is a unique UI framework.

      • Mike-EEE commented  ·   ·  Flag as inappropriate

        Hey, would you look at that? This idea is over 5,000 votes as of today. I am personally humbled and amazed to see the success it has received over the past year. Thank you to all who have shown and continue to show their support!

      • shimmy commented  ·   ·  Flag as inappropriate

        Looks like iOS and Android have been targeted by Xamarin which has now been made completely free for the community.
        The real important thing left here is making a .NET client for web, thus having a compiler that emits HTML5+CSS3+JavaScript from XAML+C#.

      • Adam commented  ·   ·  Flag as inappropriate

        I have been chasing the moving target that is the .NET Framework ( and all the parts of the framework ) since that time years ago when I fell in love with C#. The .NET Framework is now so complex that it can't be easily described to someone who has no concept of it already. C#, which was my favorite language for years, has become arguably more complex than Java (this makes it much harder for developers to come to understand and ultimately become able to use the language to solve a problem that they could easily code a solution for in their favorite language, but because C# is so large now, and so complex, it has lost the elegance and simplicity that the C# I learned initially.
        I am all for this proposal. A .NET executable *should* be able to run on any machine for which the framework has been implemented, just like the JVM with Java. .NET should mean write once, compile once, run everywhere, Instead of the cluster duck that is .NET. You need an expert just to make sure that I refer to each part (be it a subset of the .NET framework or a superset (or even some other set)) by the precisely correct name. Most software is low quality, quickly written, and barely adequate as far as functionality and speed. There is a very good reason for this too: It is hard to write good code.
        What we is simply for those who decide they need to invent a new language, runtime, framework, or application software stack that is coded to a contract. Ideally, that contract would be a document generated by the governing standards association, such as IEEE, or an ISO standard document. That way, instead of everybody reinventing the wheel all the time, we could actually use a wheel that we or someone else already created. We could do that with other parts too, and we would know that after assembly was complete that the whole system would work properly. We would know that because each and every piece of software in each and every sub-system or component parts would be written to a standard.

      • Shawn Alexander commented  ·   ·  Flag as inappropriate

        Would you buy a car that had two engines, and each engine had to be taken to a different repair shop for maintenance and repair? That's exactly what MS has done with combining .NET and JS, and requiring JS to create web applications. Truly maddening that they cancel the one technology that would keep a single engine in the car, Silverlight, and then replace it with this two-headed cluster that we have had to endure for over half a decade now.

        This also explains why every shop I know is switching over to NodeJS and getting rid of .NET altogether. NodeJS is a highly functioning, one-engine car and works everywhere. Everyone else is driving around in two-engine cars looking like a bunch of overpaying and clueless idiots, courtesy of MS!

      • Josh McFadden commented  ·   ·  Flag as inappropriate

        > Yes, because there's already a mature ecosystem for developing user interfaces for iOS and droid with browser HTML & CSS

        Whut? You cannot run iOS/Droid in an HTML5 page. Please explain.

        > You would be better served utilizing Xamarin, or asking that Xamarin be modularized into libraries that people can use from .NET Standard app models (this I could get behind).

        This is exactly what is being asked for here, but for the web. The web is simply another platform like iOS/Droid. You wouldn't know that from all the conditioning and poor guidance that MS has provided up to this point, but innovative thinkers such as JSIL/CSHTML show that HTML5 can be a platform and .NET can run on it.

        > If you want to throw in your bets with CSHTML, go for it, but personally I'd wait till the technology has more to it than a bootstrap template and the promise of a free beta.

        You do realize this is an idea/suggestion site, right? The purpose of this site is to petition Microsoft for ideas and to see the user demand for such suggestion. This idea is nearly 5k votes after a year. There is clearly demand here, and also with products such as CSHTML show a viable path forward.

        You sound just like those developers that said .NET couldn't be done in an iOS/Droid/Linux/cross-platform way, and then when Xamarin proved them wrong, they started complaining about the pricing and cost structure, and then when Microsoft acquired them they were suddenly saying that Xamarin was such a great idea all along and why didn't it happen sooner.

        This is no different. JSIL was started by a single genius kid developer in 2011. CSHTML5 is a team of developers using that codebase with a little more than a year under their belt. Imagine if Microsoft had done the right and smart thing back in 2011 and pursued this path rather than dancing like a bunch of fools on stage at Mix'11 trying to fool developers into thinking HTML5 was a good idea.

        Imagine if an entire division was dedicated to this since 2011, or about five years. This is about the amount of time it took to get to Silverlight 5, which was a remarkable release. All the problems you mention would be solved and accounted for. This is what we are asking for, and what this IDEA and SUGGESTION site is about!

      • Sherbet commented  ·   ·  Flag as inappropriate

        @Josh Yes, because there's already a mature ecosystem for developing user interfaces for iOS and droid with browser HTML & CSS. Browser layout and scripting engines work identically on those platforms.

        Instead of utilizing the well specified environments and languages that browsers have been converging towards over many, many years, you want to try and build code against a proprietary runtime, then migrate its bytecode piecemeal to the browser runtime(s!). All this in addition to native platforms where even headless .NET code does not run yet. You would be better served utilizing Xamarin, or asking that Xamarin be modularized into libraries that people can use from .NET Standard app models (this I could get behind).

        If you want to throw in your bets with CSHTML, go for it, but personally I'd wait till the technology has more to it than a bootstrap template and the promise of a free beta. I guarantee you will be tied to their limited dev cycle, will have to work around their quirks, and after building an esoteric codebase that you can't bring new developers up to speed on, will be scratching your head as to why you didn't just build in the HTML+JS the XAML will compile to.

        For a fun exercise, try taking a modest C# codebase (e.g. implement tic-tac-toe using Console.WriteLine), build, and transpile the bytecode with JSIL, the technology underlying CSHTML, and see how long it takes to serve the resulting 10s of MB to a browser.

      • Josh McFadden commented  ·   ·  Flag as inappropriate

        @Sherbet: do you feel the same way in regards to iOS/Droid? Do you want to build a completely different codebase for those platforms, too? This is the same difference, and as CSHTML is showing, it can be done: http://cshtml5.com/

      • Sherbet commented  ·   ·  Flag as inappropriate

        Given how popular this idea is, I'm probably going to get slaughtered for this, but mixing in "HTML5" as a platform and wanting them to do magic translation behind the scenes is asking for another web forms.

        We're developers. We should understand how distributed systems like websites work, and how to architect them to avoid excessive work. You can already build sites where the server is nothing but a few API routes, and if you use an API enabled database you can skip that altogether. You only need a server-side .NET codebase if you actually have non trivial work to do server side. If you're building a CRUD application and are ending up with unmanageable duplication of code and logic in the client and server you're just doing it wrong.

        Believe me when I say you are simply not going to survive out there without learning CSS/HTML/JS one way or another. Using XAML to attempt to program for the web is doomed to failure, especially now that Microsoft does not have the heft in the browser market that it used to. Trying to fight the ecosystem is only going to result in more heartbreak. Its not that hard; the market is awash with JS developers, Microsoft is building TypeScript, Visual Studio has good support, life is good. You can make it, just start switching gears now.

        This is not to say .NET isn't incredibly useful on the server/desktop. This is where we need more polish. The path towards ubiquitous .NET is continuing what the .NET platform standard and Core have started; building an thriving ecosystem of small, reusable, open source tools components.

        We need libraries, not more frameworks.

      • Anonymous commented  ·   ·  Flag as inappropriate

        Personally I think that this direction is a must for the future, if only to cope with the Internet of Things and all that encompasses. However eprom-type frameworks are advanced and fine for most situations but due to the increase of visualization devices connected to applications, some thought should be given to integrated proper Responsive Technologies and how these can be interlinked with the VS development. For example, the devices planned for my new kitchen do have displays, internet access and Ethernet connectivity. What I don't want to do is develop numerous domestics applications to suit display devices. Having said that, there are many examples where ubiquitous devices have severely gone wrong - I don't need my toaster squabbling with my kettle or my fridge ordering products just because it feels like it. And it would be very nice to have a single ubiquitous programming framework and language to deal with all this rather than a multitude of software technologies. There is only so much I can keep up with in my life both at home and work. However, great you are thinking along these lines.


      • Wait MS Resp commented  ·   ·  Flag as inappropriate

        Hi, Microsoft, It's a great chance to change the world!
        Many years later, developers will tell people: "At that year, Microsoft's universal .Net development platform changed the software development world and bring developers to a new era!"

      Feedback and Knowledge Base