Using system.windows.forms on Mono develop on Linux

I have been using ubuntu 10.04 and recently 11.10. I have mono develop installed thro synaptics or ubuntu software centre.

I have been doing c# and windows forms programming on visual studio on vista.

However, I have never succeeded in making system.drawing or system.windows.forms available in my mono develop on ubuntu.

The mono site advertises that system.windows.forms come installed with my mono installation. How can it be, I cannot find it? The mono site does not even have link for me to download the system.windows.forms libraries.

I need to get on with writing c# + winforms apps on linux, but which I will deploy on windows vista. Even though I have visual studio on my dual booted ubuntu/vista, I am a multi-threaded multi-tasking creature where I will perform both windows .NET and linux programming simultaneously. Therefore, I have to do my multitasking on ubuntu. No, do not suggest cygwin.

I cannot locate any system.windows.forms tools in mono develop on my ubuntu. All I can see is GTK# tools, and I am not interested in GTK. Please advise. Do I have to download windows forms libs for linux separately? Are there special steps which I have to make, which the ubuntu mono installation somehow failed to make, in order to have winforms tools available on mono develop?

[BTW, please refrain from politically charged questions/statements about why I am using windows technology on linux, vice versa]

System windows forms linux

System.Windows.Forms for .Net Core running on Windows and Linux

This is a early stage and experimental port of Mono’s System.Windows.Forms and a few additional libraries to .Net Core 3.1. This allows Winforms code to run on both Windows and Linux (and possibly MacOS in the future).

Rather then porting Mono’s implementation of System.Drawing to .Net Core 3.1 I ported Mono’s System.Windows.Forms onto System.Drawing.Common. Note that on Linux you will need some native libraries.

Even though this is highly experimental and unsupported it does work (at least for me).

A Demo on my Raspberry Pi 4, built and running on the Pi using .Net Core 3.1.

Windows — None known

Linux — Several native libraries, at least libx11 (libx11-dev on Ubuntu) and libgdiplus (libgdiplus on Ubuntu)

Mac — Not currently working. The Mono code that this is based on was 32 bit only. .Net Core requires 64 bit so until that is done this will not work.

There are three samples: SimpleTest (which uses my .Net Core Winforms), SimpleTest.NetCore (which uses the official .Net Core Winforms) and SimpleTest.NetFX which uses Net Framework. This also shows how to use the same source code with all three different platforms as the code is added as a link to the NetCore and NetFX projects. This way you can use the officially supported and nice looking Winforms on Windows.

To test this on Linux simply dotnet run in the SimpleTest folder.

More samples are coming soon TM. This will include more complex forms and more demonstrations of using the different libraries for different platforms.

I tested the SimpleTest example on Windows, Raspbian Buster and Ubuntu 20.04 using .Net Core 3.1 Release.

Unknown right now. I will likely add more samples and fix issues as I go. If Mono adds support for Mac 64 bit I will port that over.

I will add better Linux documentation as I have time.

WinForms

Quick Resources

Code Status

Support for Windows Forms 2.0 is complete. At this point, we are largely just fixing bugs and polishing our code.

About System.Windows.Forms

System.Windows.Forms (aka Managed.Windows.Forms, MWF, Winforms) is one of the many GUI Toolkits for use with Mono and is compatible with Microsoft’s System.Windows.Forms. Support for Winforms 1.1 and 2.0 has been completed, and is now in a maintenance/bug fixing state.

System.Windows.Forms in Mono is implemented using System.Drawing. All controls are natively drawn through System.Drawing. System.Windows.Forms implements its own driver interface to communicate with the host OS windowing system. Currently, we have drivers for X11, Win32, and macOS. These drivers translate the native window messages into WndProc compatible messages, to provide as much compatibility with native .Net as possible.

In terms of integrating visually with the desktop, we currently ship with a classic Win32 theme.

Contributing

Currently, all of the controls are pretty much complete. We are now mainly fixing bugs in our implementation. See Bugs.

If you would like to contribute, you can:

• If you find a bug in one of our methods, you can file a bug with a small test case.
• You can fix a bug in one of our methods, either that you found or from our bugs page.

Please note there are a few rules for contributing to Winforms:

• The general rules from Contributing, especially the Special Notes at the bottom.
• Controls must be drawn using System.Drawing code.
• Drawing code must be tied into the theming interface.
• If your method can be tested by an automated NUnit test, please include a test as well.

If you are working on a large feature, you may wish to post your intent on GitHub to prevent duplication of effort.

Drivers

There is a per-windowing system driver which performs the following tasks:

• Keyboard input
• Window creation
• Event translation

Mono’s Windows.Forms implementation translates the native system events such as X11 into Win32 WM_ messages and dispatches them using the WndProc mechanism. This allows applications that depend on overriding WndProc to get some features not exposed by the APIs to still run.

Accessibility

Currently Windows.Forms does not support accessibility, this is being worked on in a separate project that started in January of 2008. See the Accessibility page for details about how this will integrate into the system.

Sample Code

Sample applications for Mono’s Windows.Forms are available in winforms on github

Theming

This section discusses the theming issues in Mono’s implementation of Windows Forms as these questions are asked frequently:

Why Not Use Native Widgets?

It is not feasible to use native widgets on all operating systems. Each OS/Windowing system has different behavior/properties/features for what on the surface looks like the same widget. A RadioButton in Gnome is different from a RadioButton in Win32, which is different from a RadioButton in macOS. To use the native widgets means to reduce the functionality of MWF to the least common denominator of all supported operating systems. If we were designing our own GUI toolkit, this might even be acceptable, however we are implementing an already defined API with defined behavior (and even with application relied-upon side-effects). A RadioButton has to behave exactly like it behaves on Win32 with MS.Net, or else applications written for it may not work properly anymore. And that’s the whole point of Winforms: to allow existing .Net SWF apps to run on Mono. For other uses, there are other choices that may be more appropriate, such as Gtk#.

Fitting In

Although we cannot use native widgets, we still would like to make a reasonable effort to achieve a more native “look and feel” on different platforms. To accomplish this, we have created a theming interface with the hope that in the future it will facilitate our controls looking more native. Having a separate theme class from the get-go forces those who are writing the controls to design code where the drawing code is not integrated and intermingled with the control code.

Maturity of the Theming Interface

Currently, we have the default managed Win32 Classic theme and a native Windows VisualStyles theme. We would like to have native theming on Linux and macOS.

The best option we currently have for theming is the VisualStyles theme. On Windows, this calls the native Windows API and allows it to draw natively for us. Unfortunately, the System.Windows.Forms.VisualStyles namespace is not currently implemented on Linux or macOS. The best way forward would be to implement this namespace on those platforms. (Alternatively, one could port Wine’s uxtheme.dll and we could ship Clearlooks and Aqua themes that people have done.)

The VisualStyles namespace allows you to focus simply on drawing one element, like a “selected button” instead of having to try to sift through the theming code to find out how it draws a button.

History

There were two previous attempts to implement System.Windows.Forms in Mono. These initial attempts were done on top of other toolkits: first Gtk, then Wine. Each one had its share of problems, causing it to be abandoned.

The Gtk effort had the following problems:

• Mapping one toolkit’s semantics to another was very hard.
• It would be very cumbersome to map all events into WndProc events, the messaging system at the core of Windows.Forms.
• The development effort happened early in the Mono life, with this very sporadic development effort, the code quickly became obsolete or bit-rotted.
• Using this on other systems required a Gtk+ installation on the target system (macOS and embedded devices would have suffered the most).

The Wine effort could have been a successful approach, however there were several technical obstacles:

• Multithreading support. Wine has a specific thread setup that is not compatible with Mono. While this was solvable, it would have required larger patches to Wine.
• Dependencies. To have Mono and Wine interoperate, a glue library was required. This library required to know where Wine was installed to (we had a Wine patch that eased this requirement, but it was not accepted into Wine).
• Moving target. Key functions in Wine changed often enough that with every Wine release we had to start over making our glue code work again, sometimes becoming incompatible with previous Wine versions.
• Wine/Gdi+ interactions: The way System.Drawing had to be made compatible with Wine was extremely inefficient. Wine uses the GDI model (raster painting), while our System.Drawing implementation, built on top of Cairo, uses the GDI+ model (compositing model). Making them both talk was extremely inefficient as every transition from one model to the other required the bitmaps to be copied.

The current approach is to implement all controls fully in managed code, and uses an abstract theme interface to paint the widgets. The default theme interfaces renders the widgets using System.Drawing.

Webbrowser Control

Information about the WebBrowser control can be found on the WebBrowser page.

Где взять шаблоны WinForms для Monodevelop?

Собственно, а где? Есть консольный проект и Gtk, а где Winforms?

OS: Ubuntu 12.10 64-bit Monodevop v. 3.0.3.2

inb4: юзай Gtk#, пиши на С++ (и юзай Qt) и т.д.

Нужно написать приложения используя именно Winforms.

Эту ссылку я уже нагуглил, только там для Monodevelop 2.4,а тут 3.0. Да и хотелось бы просто дебку, что просто поставил и все заработало

Я тоже слышал что для MonoDevelop есть winforms designer.

Кста, winforms на Linux всё такое же кривое и тошнотворное? Или нормально выглядит? Я не говорю нативно, а хотя бы не криво.

К тому же, виндузятники часто расширяют свой виндормс костылями и коммерческими хакнутыми либками и контрольчиками. В Linux/Mono их нет и не будет. Стоит ли связываться с недо-фреймворком без расширеного набора виджетов?

Или тебе просто несколько формочек набыдлокодить, т.е. не серьезный крупный проект?

Я тоже слышал что для MonoDevelop есть winforms designer.

Да хотя бы шаблон, ибо:

вообще никак не собирается. using System.Windows.Forms и мы работать не будем.

К тому же, виндузятники часто расширяют свой виндормс костылями и коммерческими хакнутыми либками и контрольчиками. В Linux/Mono их нет и не будет. Стоит ли связываться с недо-фреймворком без расширеного набора виджетов?

Не просто фиолетово, а ультрафиолетово.

Или тебе просто несколько формочек набыдлокодить, т.е. не серьезный крупный проект?

Угу, именно пару формочек.

WinForms просто работает.

Запускал приложение на нем, все хорошо.

Сейчас попробовал, проект собирается и работает.

Сейчас попробовал, проект собирается и работает.

Можно по подробней, а? Т.е. совсем для чайников: какие файлики правил, где эти файлики лежат, а что куда копировал. Ибо я полный нуб.

Да, те что не используют нативные вызовы — действительно хорошо работают.

Нужно добавить ссылку на System.Windows.Forms в solution и написать реализацию InitializeComponent. Но создавать формы без визуального редактора — сомнительное удовольствие.

Как проект делался? В MonoDevelop? Там же надо библиотеки winforms вручную явно подключать. Я когда-то тоже пробовал, не собирается если вручную не подмухлевать.

Нужно добавить ссылку на System.Windows.Forms в solution

и написать реализацию InitializeComponent.

Я так понял Mono это не эмулятор .NET, как Wine не эмулятор Windows. Я раньше думал, что Mono намного лучше совместим с .Net (во всяком случае, лучше чем Wine с Windows). А так это какой-то недоклон.

P.S. А где можно посмотреть таблицу совместимости .Net/Mono?

Я когда-то тоже пробовал, не собирается если вручную не подмухлевать.

Да, уже понятно. На виртуалке в MSVS 2010 создал проект, посмотрел что используется System.Windows.Forms, System.Drawing и т.д. Эх, а жаль нету шаблона как Visual Studio.

Я так понял Mono это не эмулятор .NET, как Wine не эмулятор Windows. Я раньше думал, что Mono намного лучше совместим с .Net (во всяком случае, лучше чем Wine с Windows). А так это какой-то недоклон.

Да, оказывается нужно использовать .Net 4.0, а не 2.0. А вообще сколько мажорных версий .Net? И как они совместимы с Mono?