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!
cs mr commented
This project is mostly done. Xamarin.Forms already has most of these items, with only 2. Legacy Windows to come (and 3. and 6. in preview). 7. is not on the roadmap but once you have all the platforms covered with native solutions, you do not need a web solution. https://github.com/xamarin/Xamarin.Forms/wiki/Feature-Roadmap
Sorry brogrammer... if there is one thing in all of MSFT that is worse than UWP it is IE. You're on your own there, I'm afraid. ;)
Mike-EEE, OOui does look very promising. I hope the project continues to grow. Presently, I was only able to view the examples in Edge rather than IE. Perhaps there's some security setting that needs changing?
balazs hideghety commented
Yes, especially IoT device support could be released separately! Some 3rd parties based on MONO does exist...
Heh heh Aaron, yeah ... about that UWP. Installing that bloated SDK on your machine via Visual Studio takes about a day. Same for Xamarin's Droid experience. I got mass respect for Xamarin for the magic they have pulled off to get .NET working on Droid, but there's a LOT involved in getting it to work on a developer machine. UWP, OTOH, seems like they have put every second of every "employee" in their organization to destroy the MSFT brand. When they actually get around to doing any work, that is. ;)
Now, compare this with working in a web page. You don't have to install any grueling SDK packs or muck with any emulators. It "just works" and is incredibly lightweight. This is why I am so sprung around the WebSocket Bridge approach as demonstrated by Ooui that I mentioned earlier. The same lightweight code that is used to work in a webpage can also be used in a native environment. You could do 99% of your development by viewing it in a webpage (no WebAssembly required!) and spend the remaining 1% deploying it to native hosts to make sure it works there. In theory. ;) Very promising stuff.
Well for me, it's .xbap (or at least WPF) until the wheels fall off. I work for a large Fortune 200 building internally LOB apps deployed to a Citrix Zenapp farm, so cross-platform be damned. I am one of those unrepentant crazies who appreciates being able to write strongly-typed , object-oriented C# code in WPF without having to learn a half dozen ****** little scripting frameworks every few months. And since my apps run on server that sits physically next to the database server, they happen to be faster for remote users than my counterpart's ASP.NET apps.
Only downside is I am now am getting one project where they don't want users to have to log into the Citrix portal. So I threw the .xbap up on a SharePoint, which works fine for the next 5 years or so, as long as Internet Explorer continues to exist, then I suppose I'll have to route everyone through the Citrix Portal and hear all the attendant gripes about logging in. Too bad the HTML5-shilling , Google-wannabe idiots over at the Edge development team would much rather have pages load a couple nanoseconds faster than to continue to support a format that is a perfect fit for intranet development in oh, say, about 80% of the largest organizations out there. I guess I know how you Silverlight guys must feel now!
If Microsoft isn't going to give us Silverlight vNext because they're so worried about cross-browser and cross-platform compatibility, the least they could do is make the latest Windows browser support XAML in a browser in one format or another, for the benefit of the great many of us business developers who don't give two ***** what Apple and Google are up to and just want to deploy to our intranet windows users. UWP through hyperlink ? Yeah that might be an option if the many remaining Win7 user's machines all breaks at once and users get upgraded to Win10 overnight...and if I can somehow work through the built-in security hurdles. I'm curious how many UWP success stories there are from former Silverlight or WPF/xbap developers. So far I haven't even been able to compile a UWP without security hassles....
Yeah, I gotta say I am very drawn to Ooui's approach over Blazor's ATM:
As I mention there, it doesn't support data-binding (yet ;)), and other issues, but consider that this works in all four platforms: iOS, Droid, Windows, *and* web. Additionally, with the web scenario, you aren't faced with the prospect of massive downloads (or a proprietary technology that requires codified agreement between Google, MSFT, and Apple, blahhh). The websocket magic sends all the information back and forth between client and server.
Even better, this allows us to sidestep Xamarin.Forms and UWP altogether. ;) ;) ;)
What about PWA (Progressive web apps) and C#/WASM? looks like a great thing if we could build C#/WASM websites that also run fast and like native on mobile, desktop, etc
Warmer... getting warrrrrrrmer...
- Does not require store apps for Windows or Mac
- Object serialized on one platform can be deserialized on any other platform without extra work or loss of floating point number or integer number precision
- Development tools, libraries, packaging, etc should be runnable and able to build production applications without accesssing a third party store, web service, etc. This is needed for any realistic long term support policy. I should be able to rebuild and redeploy a product 5+ years in the future after its first release.
Software escrow is an important part of large scale commercial software enterprise solutions.
Reliance on 25 different third party or second/third tier MS libraries is a failure risk 2+ years after the first production release.
A $1+ million budgeted project with a lifespan of 7+ years for corporate document retention requirements is unlikely to include any short-lived, 2-3 year, components.
As said elsewhere, 2 to 3 developers, a github repository, message base and few random blog posts does not make for a reliable and long lived component.
EwE dev team commented
Yes, this would be fantastic to see happen
Marc Roussel commented
I think it's ok. We don't need it anymore ;)
Right now I'm doing a BIG project in JS/Razor/C#/Html/CSS/Jquery/Ajax and everything else and I had to forfeit with their old Telerik RadGridView and go with CARDS instead. No more fency rows with cell colors, filters, aggregates and validation made easy. That time is the past. Now it's CARDS and simple
For those of you all into Telerik: https://www.telerik.com/platform-next-level
btw, manifold.js has become Progressive Web Apps builder - http://docs.pwabuilder.com/
Erik D commented
This idea is possible with current Visual Studio.
I use a custom Web MVC framework in combination with ASP.NET Webforms (pure for clean lay-out, don't use viewstates etc).
I can deploy to Native App trough Trigger.IO or PhoneGap (Windows, Android, IOS).
Yoram Bucks commented
The server sends textual information – not graphics, I am using standard http requests and exposed to any known hole, I am using a unique token (similar to the ASP.NET session id mechanism), some of my customers installed it under https protocol for better safety.
I built it as add-on to VS and am using VS+C# for development and debugging.
In the beginning I used native run time environments.
It took me a while to develop a steady and fast HTML run time that works in all major browsers; for now all my desktop clients are using it. The main trick was building a generic ASP.NET site that helps the JS with the heavy staff.
I am not sure I understood the question about copy and paste text.
There are many more issues I had to deal with; I think it worth a face to face meeting, demonstration and explanation.
Marc Roussel commented
@Yoram Bucks can you tell us what you will do about security which any fake graphic sent from the server to the client would be as real as anything else ? What a big change just to make sure we can copy and paste texts, having a debugger tool for that and finally all this has a huge cost in regards to browser implementation of that change.
Yoram Bucks commented
No doubt that designing with tag/XML language and adding handlers with code is the most popular way of developing a front-end.
JS is bad, it creates spaghetti code and multi thread mess.
But a big question is whether XAML+C# is better than XML+Java for android?
XAML is lot more sophisticated but it is hard to learn, there for only developers that had crossed over this barrier love it – but it is a big barrier.
XAML+C# is popular among organizations that can organize and afford courses and support for their programmers; and it limited for inside use.
The issue is that the market demand HTML for desktop and native for mobile and you cannot fight this.
Couple of multi-platforms tools tries to give a generic XAML+C# and compiles it to different platforms, but it is not an easy task, first of all the C# that you know is rely on .Net and iOS and Android don't support it, each one has a totally different framework. Farther more - those tools don't support HTML.
The Approach of my tool is to translate textual information to UI (like any Internet Browser can do) and to run the code behind at the server so it run with the latest .Net framework regardless the user device O/S – users can work native or HTML.