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!
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." ;) ;) ;)
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
WOOOOOOOOOOW... NativeScript already looking a little like Xaml already. It uses the ~ for image paths and everything:
Machine learning to generate code from UI:
It will be really funny once we use the robots to resurrect Silverlight 6. ;)
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. ;)
See windows insider announcement about wrong version of os pushed and what to do
Hardy Lundsbak commented
my phone krace after update ****
Thanks David... upvoted.
David Jeba commented
David Jeba commented
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
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
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.
@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 Roussel commented
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.
Marc Roussel commented
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.