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,559 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

        @Anonymous: indeed, sharing local project code via the use of File Links is one way of sharing code. However, what happens when that file references an assembly that only exists in the server tier/runtime or the client tier/runtime? You will get compile errors when one of those projects compile.

        To be more precise, CSHTML5/JSIL does not support Portable Class Libraries (PCLs) or their equivalent in .NET Standard 2.0 (have not researched this enough to speak intelligently on this yet!).

      • Marc RousselMarc Roussel commented  ·   ·  Flag as inappropriate

        It doesn't support Telerik and many Silverlight projects were using this third party. How can this be converted. Also their migration technique is almost the same as going everything manually which can be done with MVC. Both way of migrating is a pain. Either you create a new CSHTML5 project and add all your files and have to deal with everything that doesn't work with CSHTML5 and there's lot actually or you do everything manually which is to bring all the server code on an MVC project and you work out all your return values as JSon for Ajax call from the client and you have to redo all the UI.
        My opinion is that developers should not worry about anything and just continue working with the same development tool (Silverlight) and at the end a simple button pressed will make your entire project work on the web with whatever they can offer us like WebAssemly or MVC hence conversion wouldn't be necessary. The end result will be a working Silverlight app with Telerik included. But this will never see the light and that's extremely sad !

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

        > Marc - why not wait for these guys to complete their work. http://www.cshtml5.com/links/roadmap.aspx

        @Anonymous, the pain point with CSHTML5 and JSIL on which it is based is that you cannot share code between server and client tiers (thereby saving development time and cost). You could do this with Silverlight and you can do this now with a JS-based solution.

      • birbilisbirbilis commented  ·   ·  Flag as inappropriate

        Microsoft could enhance the desktop bridge to allow publishing Silverlight OOB (out of browser) apps to the desktop Store. Would just pass the OOB-marked (in the manifest) XAP to the tool and it should just work

        Could also allow Hosted Web Apps that use Silverlight at the desktop store via an IE instance running inside the desktop bridge's redirected registry+filesystem

        Would be an extra push for going to win10 clients / store for business

      • Anonymous commented  ·   ·  Flag as inappropriate

        Marc - why not wait for these guys to complete their work. http://www.cshtml5.com/links/roadmap.aspx

        or would it not be better to move Silverlight to WPF or simply package in an installer?

        You could then build a Xamarin app designed specifically for tablet UI. Then technically you can cover Windows, Mac and Tablets.

        In future, if MS get their act together and release something decent cross platform like NoesisGUI or UWP cross platform. Then move to this from SL should be ok.

        We have done this so we can offer fast apps to all our clients on all platforms. Then we can sit in holding pattern until something better than JavaScript comes along - NoesisGUI / Avalonia with EF support or similar would be our choice.

      • Marc RousselMarc Roussel commented  ·   ·  Flag as inappropriate

        My customer for which I did a huge Silverlight app asked me how much time it would take to convert the project in HTML5. I told him it's a difficult question but I tried to give him an idea based on the fact that I actually work for an employer and I can give him only 1 hour per day, 5 days a week. At full time 35 hours a week I said 7 months but at 1 hour per day it makes 49 months.

        Lots of server side code can be kept using MVC still there's a lot of changes in regards to how the data is returned to the client and then the most difficult part is converting all the C#/XAML code on the client side in JavaScript/HTML

      • Jason AllsJason Alls commented  ·   ·  Flag as inappropriate

        XAML and C# is by far the easiest way to develop nice and functional user interfaces. Microsoft will win BIG, by providing this capability across Windows, Linux, iOS, OSX, and Android. UWP is not true UWP until it covers all devices and operating systems.

      • Anonymous commented  ·   ·  Flag as inappropriate

        I still don't quite understand why Microsoft wouldn't buy NeosisGUI and make it compatible with .NET standard, WPF and UWP.

        Surely then they pretty much have it. Or am I missing something?

        Couldn't this then run in web assembly at some point in the future.

        I mean they'd have support for all their technologies and be able to run 3D support for their glasses.

        I must be missing something, surely It's not this obvious.

      • Pranav PowarPranav Powar commented  ·   ·  Flag as inappropriate

        some langage (they claim to be multi platform (in reality bolatware)) is a piece of ****. As a .Net developer we simply laugh at the stuff the "some language" teams are trying to do (in our company) for years .b'cuz we know that we can do the same stuff in WPF in just 3-4 mnths. I know microsoft can do much more with .Net core with adding good UI(eg XAML support) , Service frameworks to it. but the biggest question is when?. hope the do it within my career lifetime(I have dedicated my whole developement career to .Net & Win technologies). will be eagerly waiting for it.

      • Marc RousselMarc Roussel commented  ·   ·  Flag as inappropriate

        Yes I agree but you understand that people doesn't have a choice but to use JavaScript as a language for the web it doesn't mean we want to push C sharp language away. The survey just mean JavaScript is being the only language used for client side that's why there is so many people using it. This is the message this thread is trying to explain. I am not scared about this survey I'm just scared about the time it takes to get us C sharp as a language for client side

      • Anonymous commented  ·   ·  Flag as inappropriate

        C# is declining in popularity and has been for the last 5 years.


        Largely because it is becoming irrelevant. Servers are mainly Linux now. ASP.net is declining. Mobile isn't supported (Xamarin is irrelevant).

        At the moment, JavaScript seems to be the product to choose.

      • Anonymous commented  ·   ·  Flag as inappropriate

        His has all come about becuase of low cost labour in Asia and other developing regions. They are skilled only with the basics like JS. In addition, you get them involume so they handle/ create a mess!

        It's like the industrial revolution of software without the quality.

        A small group of experts building a C++, C#, XAML etc platform will most likely win. Something that still allows unskilled devs to hack around in JS. That something is WASM and neosisgui looks like the ideal independent experts environment (possibly avalonia.net).

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

        So I completely refreshed my local and development environment last week, completely reinstalling any and everything I owned and upgrading it to the latest and greatest, including Windows Creator Update and VS2017. This also means that I haven't gotten around to wiring up the vote counter, but I am not exactly rushing to do it. I think everyone here gets the idea. ;)

        In any case, I am checking out an ambitious Plan B in case WebAssembly doesn't pan out: client-side virtualization. It is only valid for always-on/connected scenarios, but you essentially pipe your application through a remote desktop. So you could develop in it anything if you wanted, even WPF.

        Azure actually had something like this called RemoteApp, but it was domain-joined only. They they pawned it off to Citrix. I have an open question in their forum which you can follow (or chime in with interest) here:


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

        Truly is frightening how pervasive and common the thinking is to "just use JS." It has infected the typical developer as much as it has MSFT, the source of such inflicted thinking. Look no further than the scourge of TypeScript, which not only reinforces this cost-intensive thinking, but confuses market space that we are fighting so hard to save.

        At some point, everyone will understand: two codebases are more expensive than one.

      • AnonymousAnonymous commented  ·   ·  Flag as inappropriate

        @Anonymous Javascript is not as productive/good as c#

        I also dream one day we can do web front end in XAML and C# with good designer, or at least HTML/CSS and C# but i dont want to touch javascript.

      Feedback and Knowledge Base