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)
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)
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!
@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!).
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 !
They say you can share code between client and server. Just no support for Ria services. Unless I'm reading it incorrectly?
> 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.
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
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.
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.
Jason Alls commented
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.
Aaron Huang commented
Microsoft is standardlize XAML with XAML Standard:
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 Powar commented
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.
The Stackoverflow 2017 survey says:
"In the five years we've been collecting the Developer Survey, we've seen languages such as Python and Node.js grow in popularity, while the usage of languages like C# and C has been shrinking."
XAML Standard 1.0 just announced!
C# is declining LOL
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).
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).
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:
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.