Cross platform WPF


@mcwumbly, Eto.Forms actually works pretty well compared to XWT. The main driving force for me was underlying support for WinForms as a rendering engine (which XWT doesn’t support).

The main reason for this was WinForms GDI text rendering. When ClearType is disabled on Windows 7/XP systems WPF apps have blurry text. Native WinForm apps (with ClearType disabled) text appears crisp and apps respect non-aliased text rendering of the underlying rendering engine. So, any app using Eto.WinForms works and renders like any other native WinForms app.

+1 for Eto.


@HarikrishnaMenon this is very nice ! Do you have any news ? any results after the investigation ? :smile:


You could port your your project to Silverlight and deploy it as an OOB.
Silverlight requires your users to install the plug-in on their machine (takes seconds), but is a doomed/dead technology that MS has loudly abandoned.
Google has dropped SL support for Chrome since version 39. Read the Silverlight article on Wikipedia, especially the first few sections, so bear in mind not to put to much effor if you do decide to port it to SL.
It also depends in the leverage of the WPF functionality your project takes. Silverlight is a subset, more correctly a tiny subset of the whole WPF feature-set.
Anyway that’s still your best bet, especially if your app has already been developed, and especially based on my understanding that that you want to develop the ‘client’ app for those platforms.

And besides, I’m sure you might find a lot of interest in my post: .NET Core for Web.


Consider Nevron Open Vision - it is a .NET UI layer with most of the WPF functionality (like advanced property dependencies, inheritance, CSS styling etc) that works on Windows and MAC. I work for this company and we also have plans to make it running on Linux (it already runs on Mono Mac)…


Whilst I am all for something like XAML as a part of the .NET Core; I think that it would be extremely useful if there were some sort of general purpose binding support in .NET Core so that it’s easier to reuse application logic with different “view” controls.

It would be interesting to hear other peoples thoughts on this; I have opened a feature request issue ticket here:

[Feature] General purpose data binding support? #3107

I would also rather like to see a general purpose XAML template parser which makes it possible to parse and build a UI by implementing some sort of IUIBuilder interface where bindings could be wired into the general purpose binding mecanism.

In order for it to be possible to reuse existing application logic I believe that it would be good to stick to the INotifyPropertyChanged and INotifyPropertyChanging interfaces; although there seems to be some opposition to this in my issue ticket.

Many thanks :smile:


Just in case anyone here is stuck on this wondering what other people are doing, I just wanted to follow up with the solution I am going with and my personal recommendation.

The general recommendation is to move away from XAML and consider it an obsolete technology. Existing apps should continue to work and have support for a while longer but you should not create new apps with XAML based technology and you should consider replacing your application with a different technology if feasible.

There are a lot of replacement technologies out there, the one that is probably the most comparable at this point and the one I recommend people switch to is Electron:

Good luck everyone, and R.I.P. XAML :disappointed:


Look at what the “Spotify” guys did. They built a c++ client, that is just a shell for chromium engine. The whole UI is (propably) HTML 5 / JS / CSS. I think, the link to the electron/atom is nearly the same concept, that Spotify did.

And always remember this: The normal user does not care, what technology is behind something. The normal user just wants a fast, beautiful and crash-free UI, he can play with. No matter if WPF or JS/HTML.

From a developers point of view, XMAL/WPF with all it’s possibilites to build decoupled applications, is the heaven.

And I think WPF will be here for a long time. Just because every bigger enterprise in the world (!!!) is de facto using Windows clients for it’s IT infrastructure. Show me one bigger organization that relies on iOS or Linux. You wouldn’t even be able to read any Microsoft Office Files without the known problems.

So if you live in the LOB world, WPF will stay. If you live in the consumer/tablet/phone world, cross platform matters.


First off, I just want to say what an INCREDIBLE and informative thread this is! Wow. I just read all 70 posts and I am seriously overloaded with all the information contained in this thread.

@justinmchase - I appreciate you moving on, but I wouldn’t say there’s a general recommendation to abandon Xaml. Xaml is alive and well in every major MSFT group except for ASP.NET (and this should be fixed, LOL). Xaml is also very much alive in Xamarin as well.

However, I do feel your pain when it comes to cross-platform/web-based Xaml.

As for your recommendation, it comes with it’s own problem… a big one: when you want to share code between client and server. A common assembly that can live in the server application boundary, and also the client application boundary. This is something that can happen in .NET solutions but not web solutions. You end up having to create the same components in both server (C#/.NET) and client (JavaScript). This not only violates DRY, but incurs additional cost to the overall solution, as you’re now managing/maintaining two versions of the same conceptual entity.

In any case, I would definitely say with 70 (really amazing) posts on this topic, there is definitely a need for a consistent, ubiquitous cross-platform .NET client application model that works not only in compiled (native) runtimes, but also transpiles into HTML5-compliant artifacts and works on websites as well. Something that hits EVERYTHING. And no, it’s not impossible. It will just take some time.

Having a unified, official cross-platform library for Xaml serialization would be awesome, too. :stuck_out_tongue:

Perspex / OmniXaml / Noesis have all got my attention. I was unaware of any of these until today. EmptyKeys is also cool, too. :smile:

Anyways, great thread. Really enjoyed the read.


This is something that can happen in .NET solutions but not web solutions.

Using nodejs on the server and electron for the client, you can easily create packages that can be run on the client and the server.


Psst… you’re in a .NET forum, not a node.js forum. :wink:

And I agree/understand, and don’t blame you. You’re 100% right and hopefully MSFT management will see how terribly expensive a problem this is – not just from a monetary perspective, but from a mind share/branding perspective, too. You are not the only one connecting those dots, and it is only a matter of time before organizations in full will be switching entirely to Node.js/JavaScript solutions for both server and client… and then where will .NET be? From my perspective, this is one of the biggest problems facing MSFT today and is the reason why creating a comprehensive, fully ubiquitous .NET client application model is so paramount.


Hi guys, just to let you know that Perspex (a cross platform .NET UI framework inspired by WPF) has just released alpha 2:

Hopefully this isn’t spam; some of the people who discovered it on this thread asked me to post it here!


From @Clockwork_Muse’s post above it sounds like you can discuss projects that are open source. I don’t consider this spam and think it’s quite relevant. We need active answers to this problem now, not a bunch of conjecture and musings that lead/delay us to wait a few more years until someone finally decides to get their act together. :stuck_out_tongue:


Agreed with @DragonSpark FWIW - your post is definitely not spam @grokys. The community might take a different view if it was a closed source solution or vaporware but what you are doing is incredibly relevant to this thread and so welcome (and congrats on the Alpha 2 release)


I think what makes something spam is when it’s a whole “ad” for the framework, not a quick note about it


FWIW, I have published an article that references this (incredible, really) thread, while exploring the problem that .NET client application developers face today in lieu of a ubiquitous client application development model offering from Microsoft. Sadly, as @justinmchase has illustrated, the logical choice is to move away from MSFT-based solutions to HTML5/JS web solutions to better integrate and utilize code between client and server.

If interested, the reference can be found here:

Although this sounds damning, the article is part of a series with the goal of procuring votes towards creating a ubiquitous .NET client application development model that saves developers (and organizations) from having to make this difficult (and expensive) choice:


Microsoft can`t open source WPF, unless the Windows system completely free.


@DragonSpark I can’t believe that your proposal didn’t get so much attention,
ubiquitous .NET is so much needed. I was hoping in a more decisive change of direction by microsoft, after the hiring of new CEO. :frowning:


Haha thank you @0vermind for your support! It really means a lot. FWIW, I am running weekly vote reports on that idea and a few others. You can see them here:

Speaking of the CEO, I am actually sending a kind, weekly ping (tied to these very reports) to Mr. Nadella (and the Visual Studio and Windows Platform handles), reporting the total vote count from the cumulative votes for the ubiquitous .NET client application model. If you would like to show your support, please feel free to like/retweet. The latest one (as of this morning) can be found here:

FWIW, as of this morning there are currently 24,020 votes identified from 9 different votes/suggestions that are asking for a ubiquitous .NET client application development model offering.

Thank you again for your kind words and support!


Perspex seems promising in architecture and features implemented and the road ahead.

I think an active community around such open source projects can easily solve these problems for cross platform development.


I see the reason it cant be done posted over and over that its heavily tied into directx.
This is confusing to me, If a video game can be modular enough to run on both OpenGL and DirectX why cant something as simple as (relatively speaking) part of .net be able to do the same.

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