Port Winforms to CoreFX

[fanoI]

As the porting of System.Drawing from the Mono code is in progress what are the possibilities to have Winforms ported to CoreFX?

Not having an official supported portable GUI is the only single point in which Java is in advantage...

What do you think?

[jnm2]

I'd rather have something new than WinForms, but I could not agree more on the eventual need for a platform-agnostic desktop UI. It's a rather obvious shortcoming.

[richlander]

I'm glad to see the interest. We have heard interest from others for a UI solution with .NET Core, too.

At present, we don't have any plans to build a cross-platform UI stack. We do think that .NET Core is a good base for such a project and encourage others to collaborate on that. We are focused on server apps currently and will likely add IoT apps to that next.

[fanoI]

The fact is that while Winforms could be considered obsolete it seems easy portable has been ported to Mono simply creating a wrapper of libGDI+ (the same thing is done here for System.Drawing), it exists a "try" to port Winforms to Net Core too: https://github.com/akoeplinger/mono-winforms-netcore.

But having the backing of Microsoft after this will do make things different obviously!

@jnm2 WPF has been proved impossible to port on Linux / MacOS (at least Mono never accomplished this), maybe Microsoft could make UWP portable?

[lextm]

@fanoI It is not "easy". Porting apps from .NET Framework WinForms to Mono WinForms has been proved to be painful and projects (Plastic) finally drop WinForms to embrace OS native UI framework (such as Xamarin.Mac). Typical WinForms apps use many P/Invoke and third party controls, which can be quite difficult to port.

WPF technically speaking can be ported to non-Windows OS, as its siblings such as XNA, Fire Monkey (for Delphi) have been ported. Mono never accomplishes that because they run out of resources, not because it cannot be done. There are other open source projects trying to port WPF over too, like Avalonia. Again, WPF apps can also use P/Invoke and third party controls.

@jnm2 You should check out Xamarin.Forms, which goes cross platform (iOS/Android/UWP/Tizen right now, and macOS/WPF coming), but that's not "platform-agnostic". It maps UI elements to native controls automatically so your apps blend in just like native apps, not aliens everywhere as the horrible Java apps. It also supports embedding native controls if you do need that capability.

Updated: Just wrote a blog post to cover most cross platform approaches and the frameworks that I know of. It is still far from the truth but hope it can get you familiar with the current status.

[fanoI]

Xamarin.Forms has a GUI wysiwyg designer as WPF and Winforms?

[lextm]

@fanoI Not exactly but close. It has a previewer now.

[fanoI]

@lextm I hate to write GUI code by hand... maybe I'm strange but I'm not interested if C#/VB.Net is automatically generated rather than XAML or well JSON but I want to design the windows graphically.
All the modern .Net UI frameworks are a step back respect to Winforms too in this aspect.

Interesting analysis on the current situation in your blog post, thank you!

@richlander the "port to core" label means that there is chance of this happening in the future?

[richlander]

@fanoI There is a chance. I think that @karelz added that label because that's the category of the work. I don't think he added it as an endorsement or the like. As I said, it isn't something we are focused on at the moment.

[JimSEOW]

Instead of pushing WinForm, perhaps consider pushing Blend for Visual Studio 2017 to be compatible with XAML Standard

[jnm2]

Personally, if I had any time to spare, it would be fun to do a native UI library from the ground up with all desktop platforms in mind. I've done a fair bit of native windows UI interop and once in a while winforms has gotten in the way more than anything. But realistically, that's a huge amount of work which needs an experienced team.

[Opzet]

.Net Core will rock if it has WYSIWYG Designer and it does Android + Win/Mac/Linux

Mind you the browser WebAssembly may change things? see Mono WebAssembly LLVM

[Opzet]

Winform exe's are cross platform, just launch with Mono runtime on linux/osx e.g. >mono ./hello.exe

You can develop in Visual studio and run on linux/mac using mono runtime

Prove it to yourself... Make a simple .sln Winform app, Target Dotnet 4.5. create form with button and label, create "hello world" to label on click event.

1. On Windows, click or launch from command line compiled file in solution from \bin

helloworld,exe
presto click button, -> hello world of course, works as expected

Copy same \bin\helloworld.exe to Linux/Mac/ Raspberry PI!!

2. To launch app on Linux/Mac, just prefix it with mono and use the './' before exe

Mono ./helloworld.exe
presto click button, -> hello world IT WORKS!

OMG it renders the form just like windows, and all the managed .net framework stuff just works...

---

To get latest version of mono for linux/mac
Check version.

mono --version
//Mono should be >=v5.0.1

//To upgrade mono.

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 3FA7E0328081BFF6A14DA29AA6A19B38D3D831EF

echo "deb http://download.mono-project.com/repo/debian jessie main" | sudo tee /etc/apt/sources.list.d/mono-xamarin.list

sudo apt-get update
sudo apt-get install mono-complete

---

These UI frameworks below just confuse the simplicity of cross platform WYSIWYG Winform

• Xamarin.Forms :(
• UWP IOT :(
• GTK# :(

Mono has Cross platform Winform Win/Linux/Mac, its just missing Android.

[yzrmn]

I already put some work into this: https://github.com/yzrmn/System.CoreFX.Forms
Contributions would be very welcome!

[fanoI]

I'm trying to use @yzrmn Winform on Linux (Cent OS7), I had a problem with the wrong path of libX11 that should have resolved but now I've got this exception:

Unhandled Exception: System.TypeInitializationException: The type initializer for 'System.Windows.Forms.WindowsFormsSynchronizationContext' threw an exception. ---> System.TypeInitializationException: The type initializer for 'System.Windows.Forms.XplatUI' threw an exception. ---> System.Resources.MissingManifestResourceException: Could not find any resources appropriate for the specified culture or the neutral culture. Make sure "keyboards.resources" was correctly embedded or linked into assembly "System.CoreFX.Forms" at compile time, or that all the satellite assemblies required are loadable and fully signed.

[yzrmn]

Yeah, it currently works on Windows only, there are things that need to be done to make Unix work aswell. I'm hoping for constributions on this part :)

[danmoseley]

@fanol as you probably know we expect to ship this next year (blog)

That's tracked by other means (and corefx side here https://github.com/dotnet/corefx/projects/5). Does this issue track anything else, or can you close it?

[fanoI]

But Winform / WPF / UWP will be only on Windows on Net Core 3, right?

You are considering after having in Net Core to make them xplat?

[danmoseley]

@fanol yes, it will be for Windows only (it's a straight port). We can leave this issue open to track the request for cross plat, if you like.

[neyromant]

Avalonia (https://github.com/AvaloniaUI/Avalonia)
A cross platform XAML Framework for .NET Framework, .NET Core and Mono

[markusschaber]

Yes, please, track multiplatform UI.
Whether it's Windows Forms (via Mono), which actually has been technologically outdated since its release back then with .NET 1.0, or a modern, decent UI framework: We (the developers) urgently need a cross platform UI framework for the major platforms (Windows, Linux, Mac, Android, iOS). Bonus points for web support (like WebForms our oui.aspNetCore with Xamarin.Forms). This has been stated often enough, and is constantly ignored and talked down.

[CatGirlsAreLife]

Does .NET core currently have classes like System.Drawing.Icon or System.Drawing.Image for support with resx resource files generated on Windows to be in fact a way to render them on Winforms? I think working on this classes to make them work on all the listed platforms currently should be worth it first for resx files only. And then after that consider using the current Winforms like planned for core 3.0 and maybe under the hood maybe use some things like mono or any other frameworks like xarmin in core on non-windows platforms. If I was good at gui's by hand instead of just drag, drop, resize, set event functions for the stuff to do. I would go to things that makes the cpython tkinner module which is a widely supported UI framework for Unix. But is it supported on Android or iOS? I think an option is maybe find a platform independent unmanaged library that just works:tm: out of the box on Windows, Linux, Mac, Android, and iOS and then just simply p/invoke it on all platforms?

Also unrelated but I contribute to a forms application that I am not sure will work with mono yet out of the box and not sure either if and now I can tell it's CI (appveyor) to try to build it with mono. However I might have to change the entire settings though on it to work. However if Core did have Windows forms applications like mine supported on all platforms and runs them like Windows does out of the box I would use Core on both Windows and Linux and simplify my entire build and setup on it. However with System.Drawing.Icon with it's tendency to display windows icons and maybe the fact that the windows icons file itself might be the thing hashed in the resx files. I think a better alternative for resx files is this:

On Windows: when adding a ico file to a resx file just read all bit formats and sizes of the icon formats, convert to png, then add each png image as a entry to a image massfile (imf file) that is then saved into a resx file on for all platforms to use. Just on all platforms get the display bit depth and load the sizes asked for. This could be a new System.Drawing.Icon class for .NET Core.
On Mac: take the icns or bin Mac icons and do what is in Windows section above.
On Linux: select each icon png file and simply place them where they need in the massfile.

Pro: multi platform System.Drawing.Icon class for all platforms.
Con: massfile got to store bit depth of each png image, size (in pixels), and file offset to seek to.

[fanoI]

I would like too WPF / UWP running on Linux / Mac OX but Winform is more likely they have ported already the Mono libgdi+ wrapper and System.Drawing so they have all the needed pieces to port Winform.

If in the Net Core repository there will be really the sources of WPF / UWP (but I fear they will be only wrapper to the closed source Net Framework code) the community could try to make them xplat.

[CatGirlsAreLife]

I think that is eventually the plan of .net core devs and probably microsoft already. If so I got to do a few IsOSPlatform checks on some of my ui buttons (as some of them on my program should be enabled only on win32 as the programs they execute is a windows based game that I got no source code on.

[weitzhandler]

@fanoI Such a shame you named the title of this issue with WinForms.
I would definitely NOT want to pollute the .NET Core. with the obsolete WinForms.

I do vote for having a UI rendering platform integrated as part of the .NET Core, and even as part of .NET Standard, but I'd want it to be structured like UWP or WPF, definitely not WinForms.

You should have named it "Provide a comprehensive UI framework as part of the .NET Core".

Please read this issue:
.NET UI Standard

[CatGirlsAreLife]

@weitzhandler As much as I would like the .NET UI standard, not everyone should be forced to use XAML for their UI’s if they either:

A: Do not know xaml well.
B: Do not like xaml.
C: Want to target desktop only (No Phone support at all).
D: The format of their current project is not targeting any xaml stuff.

Also I am not sure how one could manually Substitute the System.Windows.Forms.UserControl class to a xaml control (in case the user wants to convert a Windows Form/Form Control by hand). I think what it needs on documentations is a "C# xaml for dummies" type thing. Also what if the control uses "timers" like System.Windows.Form.Timer or even other things like the ContextMenuControl and the NotifyIcon control? Either way it is not clear in xaml standard yet for me what controls to port all the possible Windows Forms controls that is in the .NET framework 4.7.2 to what they would be under the xaml standard. Sure if more people probably had a guide they could possibly manually port their <form name>.Designer.cs, and <form name>.cs files by hand then. Also on xaml, is it like having the <form name>.Designer.cs file but it being a xml, and the other file remains semi unchanged or no? See this is unclear. If it is it could be feasible for me to move my forms and forms controls by converting their <form name/control name>.Designer.cs files and leaving the other files almost unchanged.

Also if desired, since I cannot use my laptop currently to even test xaml with my project, one could fork it and test it on their end though (warning some winapi is used). https://github.com/Elskom/Els_kom_new/

[weitzhandler]

@CatGirlsAreLife
Read my link to the post. I specifically state that XAML is a choice, what I want is a set of UI specifications. Much like .NET Standard, but for UI.

UserControl, Timers and all of what you mentioned exists in all technologies using XAML in this way or another. Name it whatever you want, it should be included in the .NET Standard (which should probably depend on .NET Standard).
XAML should be a means to express an existing implementation of .NET UI Standard, which is only an abstract contract.

[CatGirlsAreLife]

Ah, I see.

[2mik]

I agree with @fanoI. I suppose WinForms is still needed because they allow to very quickly create GUI applications for work not for admire. Many people that are not real developers, just engineers and hobbyists, able to contribute to our open source project because of WinForms. They will never get along with WPF or web development which are to complex for them.

[bigworld12]

@2mik what allows the quick creation of GUI applications in WinForms is the designer, not the actual WinForms libraries, WinForms designer is just a hard-coded c# library that is mapping drag-and-drop input to c# code.
the difference between winforms and wpf, is that in wpf you can actually edit the GUI as a xaml + drag-and-drop designer but in winforms you are only limited to the drag-and-drop designer.

with that said i completely refuse wasting efforts on porting a 15+ years old un-maintained library, and instead focus on porting the maintained and battle-tested wpf framework

[devmikew]

That's not correct - one can edit the c# code and ignore the designer. Though it's non-trivial.

I agree that xaml would be better.

Xamarinforms is cross platform including android, iOS, Linux etc. Again, however it isnt simple.

[Opzet]

I suggest you check out www.wisej.com

Winform Apps in the browser. Amazing stuff.

Buy me a beer later..

[2mik]

@bigworld12, I develop using both WinForms and WPF. WFP allows develop cool GUI. In real if you like creating clear layout, you have to edit XAML manually, like you do with HTML, that is difficult for inexperienced users. I work with guys whose primary skill is programming PLC. I'm sure they will never use WPF ))

[danmoseley]

@fanoI if this is now tracking cross-platform UI perhaps you could clarify that in the title.

[fanoI]

In part my desire is realizing, Winform has been officially ported to Net Core: https://github.com/dotnet/winforms.
For now the code is Windows only but the question is as there is an already Mono version of it the two will be merged so to have a real xplat version of Winform?

There is WPF open sourced now too: https://github.com/dotnet/wpf.
In this case the question is: Microsoft will take the effort to make it xplat or at least will accept community PR to make this possible?

[DickvdBrink]

@fanoI, for wpf and winforms the contribution.md explicitly states that it won't accept a PR for xplat.

https://github.com/dotnet/wpf/blob/3a696bc4fcfe4b8dd65ee856c9a089fa0ce13235/Documentation/contributing.md

We also do not intend to accept contributions that provide cross-platform implementations for Windows Forms or WPF.

[weitzhandler]

If I would want anything in .NET Core it would definitely not have been WinForms but rather WPF/UWP. Anyway, the truth is that I don't care so long as there will be a .NET UI Standard.

[markusschaber]

@weitzhandler You need to differentiate between existing applications with existing WinForms UI, which people would like to go cross platform (possibly using the WinForms implementation of Mono) and new projects (where I definitely would vote against using WinForms).

[lextm]

@fanoI Even if Microsoft won't take PRs for xplat WinForms/WPF, open sourcing the two allows whoever fond of that idea to fork and start their hacking immediately.

If we all waited for Microsoft to ship .NET for Linux and mobile, we shouldn't have seen Mono and Xamarin.

[stephentoub]

I'm going to close this issue as https://github.com/dotnet/winforms and https://github.com/dotnet/wpf are both now available, and there's no action to be taken in corefx.