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

        @Charles, thanks for sharing. Literally worth noting that this "huge challenge" is met by NodeJS/JavaScript just fine, along with being able to reach all the other listed platforms (and more).

        The literal worth is in reference to the cost involved with developing and maintaining two incompatible codebases (JS/.NET) with a .NET solution, vs. only one with JS.

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

        Nice little add here:

        Gotta say, that jump to TypeScript/JS is looking more tempting day by day, especially when we will have to start over with .NET Core, in any case.

        Oh, and no petitions/explaining required. ;) ;) ;)
        Nice to see when others "just get it." ;) ;) ;)

      • birbilisbirbilis commented  ·   ·  Flag as inappropriate

        speaking of NativeScript, a C#/XAML to NativeScript (uses TypeScript for the code if I remember well and XML-based declarative UI) converter would be interesting

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

        I am not sure what is more impressive @birbilis: the fact that someone uses this thread for an unrelated technical support issue, or the fact that you actually entertain it, LOL!

        But I guess it's good to see *someone* get *some* value out of this thing... for once. ;)

      • birbilisbirbilis commented  ·   ·  Flag as inappropriate

        See windows insider announcement about wrong version of os pushed and what to do

      • David JebaDavid Jeba commented  ·   ·  Flag as inappropriate

        there were scores of primitive java developers on Symbian platform
        when Android was released it was an easy shift for the old standard java developers to upgrade to new standard java developers

        Microsoft lost its ground on C# vs Java adoption

        What Microsoft Can do is
        Fork Android
        remove/replace Java modules with C# and F#
        repack as Microsoft Android
        and then push it to their OEMs

        developers who develop apps through Xamarin should be able to publish apps for Microsoft Android
        this will slowly grow the Microsoft Android Community

        Let Microsoft Windows be as it is
        people who wants Windows let them buy Windows
        and people who wants secure version of android let them buy Microsoft Android
        only Secure Android can only fight against Android

        if Microsoft releases new Windows Phone - android support
        Microsoft Ecosystem will take a very hard hit

        its not far to see Android on Desktops

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

        Why look at that... 7,000 votes and going strong. This is actually the #2 top open issue here in Visual Studio's UserVoice.

        Still remarkable that this was put "Under Review" without a single word mentioned by the administrators here for over 15 months now.

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

      ← Previous 1 3 4 5 16 17

      Feedback and Knowledge Base