Cross platform WPF


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.

1 Like

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.

1 Like

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…

1 Like

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

1 Like

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

1 Like

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


Yeah @Ziriax Noesis is where it is at, ATM IMO (LOL). It has recently released v2.0 and has a pretty decent Xaml model. They have working markup extensions in their C++ version with managed C# support on the way. It is free for indie developers, as well.

Also, I think this is pretty big news, but it was recently announced that Mono is porting to WebAssembly. So that would essentially put everything back together again as far as a cross platform .NET solution goes. Since Noesis runs on Mono, then it would benefit from the port.

Additionally Avalonia continues to be in the mix and they will benefit from the Mono port to WebAssembly as well.


Uno (Cross platform UWP) is probably one of the best single look across devices UI for C# / .NET there is as its building on top of work MS has already done. Wish MS could support this proj.


We need an official port from Microsoft, not some reverse engineered solution.


You will have to be patient as .NET Core is being prepared and WPF will be part of this version.
See .NET Core 3 and Support for Windows Desktop Applications
And yes, that would be the official port. There will be a Core 3 preview this year and a definite version in 2019. These things take time to be developed.
Unfortunately, WPF will stay Windows-dependant. Linux and Apple are not likely to be supported.


.NET Core 3 disgusts me, as I gather Microsoft is divvying up .NET platforms into first and second class citizens. That more or less destroys the entire reason for having a multi-platform framework in the first place.


WPF is not cross platform. .NET Core 3.0 isn’t really solving a problem other than getting everyone on a single runtime.

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