Cross platform WPF


Looks like we can rule LightSwitch out as a possible solution. :wink:


I don’t know if anyone noticed, but Visual Studio’s startup screen featured a link to Avalonia a few weeks ago. I guess that’s some kind of indication that Microsoft might throw some support behind Avalonia.

If this technology weren’t such a fledgling technology, I’d be putting my eggs in this basket rather than Xamarin Forms. Xamarin Forms looks alright, but it just smacks of the issues that web developers face in terms of cross platform compatibility issues: i.e. always having some quirk to screw you over because of some slight difference in control behavior on different platforms.

Avalonia looks like you could convert a Silverlight/WPF app smoothly over to a cross platform app, but more importantly, the UI would be the same across the board. I think that’s what is really missing from Xamarin Forms.


I really hope Microsoft will support it as the OFFICIAL way to create UIs. Currently UWP is clearly less powerful in than Avalonia by far.


Would be nice to see 3D support in Avalonia. :slight_smile: And of course, web/HTML5-compliant rendering support. Otherwise, perhaps the answer here is for MSFT to support it and put some authoritative resources behind it?


I hope so too. I noticed you mentioned that your company is switching to web apps. That is also happening at my company, and it really scares me. Web apps are not appropriate for any kind of sophisticated UI.

I have no problem with UWP. I think that UWP is a decent compromise for having all the different device types available. But, People don’t want to touch UWP with a 10 foot pole because Microsoft have not been able to sell it as a solution.
It looks like we’re all going to have to go back to the web world because Microsoft has failed to sell their concept.

Apart from that, UWP won’t run on other operating systems, so it really seems like a waste of time to implement anything on it.

So, Avalonia is starting to look like the ONLY option. I wish it were closer to being ready so that we could just embrace it right now. I wish Microsoft would put their full weight behind it - and help to make it touch ready out of the box.


FWIW, I’ve suggested the MSFT and Avalonia integration idea to the Visual Studio team with my weekly check-in to the Ubiquitous .NET Client Application Development Model vote. As previously stated, Avalonia is basically a cross-platform WPF, but without (as it currently stands) Web/HTML5 support – which could be solved via WebAssembly – and 3D model/rendering. Take care of those two bad boys and we are in business once again!


I don’t really get why the Web/HTML 5 support is important…

I don’t really understand how that relates to Avalonia…

Are you talking about writing a .NET Core wrapper which supports Avalonia for WebAssembly? In other words, what you are suggesting is that on computers where WebAssembly is installed, a package could be downloaded that contains a .NET Core App with the Avalonia libraries so that an app with an Avalonia UI would run inside a browser? Is that the suggestion?

Basically, this is what Silverlight already does in an indirect way, but without the use of WebAssembly.

How is WebAssembly any different from any other browser plugin like Silverlight? Browser plugins are really falling out of favour, and besides this, WebAssembly has nothing to do with HTML5 from what I can tell…


@MelbourneDeveloper the HTML5/WebAssembly component is critically important as it will allow .NET to operate within a browser client process. Currently, the only way to do this is with NodeJS or other JavaScript-based frameworks. When one starts to analyze this, the natural, logical conclusion that (you are seeing from developers and organizations) is that if one can use NodeJS to reach the browser client process, one can also use NodeJS to reach the server, and native hosting processes via Cordova (or NativeScript or even React Native).

As a result, JavaScript becomes the preferred, dominant, de-facto language, as it truly is ubiquitous and runs everywhere. And (most importantly), since you can share code between server, browser client process, and native scenarios, it becomes much cheaper to develop applications accordingly. I outline this in article here, featuring pretty pictures. :slight_smile:

So bottom line (literally): WebAssembly/Native browser process support is important as it will keep .NET competitive with JavaScript. Otherwise, it is cheaper to develop solutions with JavaScript and the .NET developer exodus to this language will continue.


How is WebAssembly any different from any other browser plugin like Silverlight? Browser plugins are really falling out of favour, and besides this, WebAssembly has nothing to do with HTML5 from what I can tell…

I forgot to answer this. There are two routes here. One is the one that MSFT should have done after they killed Silverlight, and that is to use a JSIL/transpiled approach, much like what JSIL has done and CSHTML5 (based on JSIL) is doing more than a year now. The problem with this approach is that it doesn’t support the very necessary Portable Class Libraries. So what you end up in a result is the same problem you have w/ JavaScript-based solutions: two projects that cannot share code between the two (which leads to more/duplicated code and therefore development/maintenance cost).

(Please note that JSIL/CSHTML5 is completely HTML5-standard compliant, with its rendering done via OpenGL and the Canvas tag so no plugin/install is required.)

The other path is one that is being finalized, and that is WebAssembly. It has support from all the major browsers and should be released as v1 either end of year or shortly thereafter. There has already been discussion by @migueldeicaza that it will be easy to port .NET based on the diligent greatness of the Xamarin team. It just needs to get finalized and available, first. This obviously seems to be the correct/right/long-term path, but I still feel JSIL is and always has been a viable plan, if the political will/resources got behind it.


OK @MelbourneDeveloper you got me chatty. I had another thought around this and started typing a bunch of words here, but decided to post it as a blog post instead. Trying to be mindful of chattiness here while also brushing off the dust, there.


@DragonSpark, what you are saying is very interesting, but I must admit that what you are saying is quite new to me, so it’s going to take me some time process this.

the HTML5/WebAssembly component is critically important as it will allow .NET to operate within a browser client process.

Well, this is quite a turnaround. We’ve been using Silverlight for years, and we love browser based deployment. But, we had resigned ourselves to the idea that browser based deployment was dead in the water. Now, there is this thing - WebAssembly which is supported by the W3C with threatens to turn this on its head.

As a result, JavaScript becomes the preferred, dominant, de-facto language

I think this is where you lose me. Are you talking about compiling JavaScript to .NET? Or, are you talking about coding the server and client side in JavaScript, and compiling the server side to some compiled JS technology? For us, the point about Silverlight is that we share code between the client and the server. This is doubly important for us because our application is an occasionally connected app which means that the client literally is a mini server. We’ve got no intention of porting our code to JavaScript in the long run.

What is appealing about what you’ve mentioned is being able to compile to something like .NET Core, be able to deploy this through WebAssembly, and potentially use Avalonia, or something similar for the UI.

I’m going to read through some of the links you posted and see if I can get a better understanding of this.

Thanks very much for the information.


I’m right there with you. We all did. I put 6 years of my life into that sucker, and Silverlight 5 was truly tops as it had the perfect blend of necessary components while not putting in the mother lode from WPF. Unfortunately it required an install/plugin. What we’re after here is the same conceptual model, but running off of either transpiled JavaScript and/or WebAssembly – the goal being 100% HTML5-compliance so that we are assured that it will run on browsers now and in the very foreseeable future.

In this case I was talking about neither. I was outlining where we are currently going in the marketplace direction (.NET developers abandoning .NET for JavaScript – as we see in this thread and others), as it is cheaper and easier to use JavaScript to build solutions across all the “big five” application boundaries (server, iOS, Droid, Windows, Web) than it is with .NET (or even Java, or Objective-C). JavaScript simply offers the cheapest offering because it can span all five boundaries, whereas .NET and other languages can only span four (at most).

You got it. It should be noted that what I am talking about is pure infrastructure, whereas Avalonia is the client model that runs on that infrastructure. That is, Xamarin/WebAssembly would provide the roads, and Avalonia would be the car you would drive on it, if that makes sense. Everything that I have discussed until now is the infrastructure to drive the cars on, and it should be noted that of course we do not have any cars to drive on the existing roads, save for Avalonia. (FWIW I am also a fan of EmptyKeys). UWP should be a car, but it only supports Windows as of today, despite many votes asking otherwise.

Thanks very much for the information.

Sure thing. I’m sorta glad I wrote it now. I can be chirpy and I try to keep it in check. :stuck_out_tongue:

Does compiling .NET code (including UI technology) to WebAssembly sound reasonable?

@DragonSpark, thanks for clearing these things up.

You certainly make a persuasive argument for porting to JavaScript. I do see your point about using JavaScript to build solutions across all the “big five” application boundaries (server, iOS, Droid, Windows, Web).

So, if I understand you correctly, what you are saying is that the best possible solution would be to convert all code to JavaScript so that the code runs in a browser as a purely HTML5/JavaScript compliant code base without transpilation, and the back end can be compiled to some server side technology. Is that correct?

But, if that’s the case, where does WebAssembly come in? Wouldn’t .NET on top of WebAssembly be an alternative to porting to JavaScript?

I do get your points about Avalonia. Will definitely check out EmptyKeys! The front end UI is an ongoing discussion point. I personally like UWP a lot, but the uptake has been terrible, but and it just seems ridiculous to be building for more or less one platform only. Windows phones are dead like the Dodo. Windows tablets are great, but we already have our app running on Windows tablets with Silverlight, and we’ve gone to great lengths to make that touch friendly.


LOL… apparently not good enough. The argument isn’t for porting to JavaScript, but to support .NET in a HTML5-compliant way, which would involve either one of the two paths (or even both as the first path is already under way in some fashion):

  1. Transpile .NET into JavaScript (ala JSIL).
  2. Provide a WebAssembly-based solution.

Note that the end result here is that you as a .NET developer never ever have to touch JavaScript, as much as you never ever have to touch Objective-C/Java/compiled code in a Xamarin-based .NET solution. What we’re after here is the web/HTML5-analogous form of Xamarin to iOS (and/or Droid).

WebAssembly is a bit of a mystery ATM. TBH I do not fully understand it myself, just that it will enable this scenario (and much much more). I have been waiting for its launch before exploring this further, and state my ignorance in the meantime. But for the purposes of this discussion it simply is a way to get .NET working in the browser process (like Silverlight) but in a standards/compliant/viable/long-term manner.

Going out of order here, but you almost have this correct. The end result would be like you would have your Xamarin solution setup, with one .SLN file, but also with a new project for web-based version of your application. To put it in a mock/prototype .SLN, it would look like:

Hello World.sln
|- HelloWorld.csproj (shared code between all projects) <— $$$ Money-maker. $$$
|- HelloWorld.Application.Server.csproj (server/cloud hosted code)
|- HelloWorld.Application.iOS.csproj (iOS-hosted/deployed code)
|- HelloWorld.Application.Droid.csproj (Droid-hosted/deployed code)
|- HelloWorld.Application.Windows.csproj (UWP/Store-hosted/deployed code)
|- HelloWorld.Application.Web.csproj (HTML5/web-hosted/deployed code)

Note that with the .csproj file type you are working strictly in C# throughout the entire process, and when you build, each project creates the necessary artifacts to successfully deploy to the designated/target platform.


So much for minding the chatter on here. Just saw this really promising article and I thought I would share. WebAssembly is sounding like the real deal. Maybe we’ll hear about it at Connect(); 2016 in a few weeks?


the end result here is that you as a .NET developer never ever have to touch JavaScript

Phew. I was starting to panic.

WebAssembly is a bit of a mystery ATM. TBH I do not fully understand it myself

It’s a bit of mystery to me as well. However, if I had to hazard a guess as to why it exists, and why it’s allowed to exist is this. Unix binaries have been considered safe for a very long time. They are considered to run in a sandboxed environment. The sandboxed environment that Unix users talk about is different to the say the Silverlight sandbox. In the Unix environment, potentially malicious code is stopped by protecting certain parts of memory, and restricting the rights of the application to perform certain operations. Silverlight works in a similar way, but the problem is that at the operating system level, runtime environments like Silverlight are not actually sandboxed. The OS relies on Silverlight to be a nice guy. If a hacker manages to jump out of the Silverlight sandbox, the hacker has full access to the OS. This is not the case with Unix based sandboxes. This is probably a naive understanding, and this is just something I’ve pieced together so feel free to correct me. I started a thread about this here: (

My guess is that WebAssembly is an attempt to replicate the Unix sandboxed environment. I.e. it is an attempt to allow natively compiled binaries to be run in a web browser without the security problems that normal binaries incur. I think that the idea is that as a programmer, you are not allowed to jump out of the sandboxed environment, and therefore pose no risk to the user’s environment. This is somewhat like Silverlight in non-elevated trust mode. However, there is no telling what security holes may be lurking in Silverlight. Just recently, Microsoft released a patch for Silverlight and my guess is that it was done to plug a security hole. The whole reason Apple took a giant swing at Java was because holes in Java meant that hackers could exploit the OS as opposed to just programming badly.

The end result would be like you would have your Xamarin solution setup, with one .SLN file, but also with a new project for web-based version of your application.

I hear you. That’s what I would like as well. I kind of figured that the Xamarin team would be working on this at some point…


well, MS has embedded Flash engine in Edge browser and left Silverlight out even though Flash has had a huge number of vulnerabilities over the years compared to Silverlight


…guess it had to do with those morons from the EU trying to fine Microsoft for wanting to kill HTML via Silverlight #LOL - We see their other achievements with those cookie acceptance dialogs that you have to click over and over again when you cleanup cookies or use multiple machines (unless we start syncing cookies now too thanks to them to avoid this #LOL^2)


You might want to look at Noesis GUI

It is not free, but is cross platform, and has some advanced extra features like linear RGB compositing and interop with DirectX and OpenGL.


There is the outdated Mono Project Olive if anyone wants to work on it. It would be great to have a WPF standard finally.

.NET Foundation Website | Blog | Projects | Code of Conduct