I’ve a windows application with both UI written in C# and C++. They are written with WPF and Winforms etc.
Can I create a docker container for this?
So, I could only find UI support with a browser but not anything on GUI support for windows application in a container.
As of now I created a c++ console exe and displaying a messagebox…and when a image/container is created and run the messagebox does not show up and the the container is stuck.
Just wanted to confirm, if this feature is still not possible or with newer releases this is possible now? Most of the threads, I am reading are a year old, so wanted to confirm.
This is just sad. There are SO many Windows developers who need WinForms support and it seems impossible to get a definitive, up-to-date, YES/NO. I asked the same question and received no reply.
Is it possible to run WinForms applications and interact with them, in a Docker container?
(No, it hasn’t been, but has anything changed or is anything likely to change?)
If so, how?
If not, can you give us any idea if this is likely to happen, and when it might be possible, please?
We have a large amount of legacy applications we would LOVE to containerize but we are just wasting time with Docker if it cannot and never will do this. If it is being looked at and is slated for the future, an estimate of when it might be available would help us to forward plan.
I don’t understand why this is so hard… Is it because it is Open Source and nobody is actually responsible for it?
@petedashwood: I don’t see Microsoft ever making Windows fully “containerizable” (i.e. including its graphical environment). Reasons: a) already having a similar offering (Windows Terminal Server), b) internal effort and/or unwillingness to open their codebase to the community, and c) a licensing structure that could be either too difficult to implement and control or prove cost-ineffective for clients. I hope this answers the question as a clear, up-to-date NO.
Possible workarounds (AFAICT): a) Linux+Wine (or CrossOver), b) Windows Terminal Server (or similar), c) Virtual Machines (Hyper-V, vmWare, VirtualBox, etc), and d) third-party proprietary solutions.
We have been forced to abandon containerization because of this and have sought other solutions.
Linux/Wine is not an option for us because it would be too big an effort to move all of the existing Windows investment to Linux.
Windows Terminal Server and VMs are a definite possibility and we are exploring those at the moment.
For myself, I am really sorry that we had to drop containerization because I really liked Docker, but the needs of the company outweigh any personal preferences I might have.
Thanks again for an excellent response; I only wish someone had been able to offer it a couple of years ago, when it could have saved us a large amount of time and effort.
It is no longer true that “Windows does not use X11”. WSL2 DOES use X-Windows.
On Windows 11 in WSL2 running ubuntu, I did
sudo apt install x11-xserver-utils x11-apps xterm
and now xclock and xterm both work from the WSL2/ubuntu command line, displaying on the Windows desktop. Command-line Linux containers run fine in WSL2/ubuntu.
But I have been unable to get any X-windows app to work from inside a container. Any suggestions? (beware of Google, as it serves up much outdated info.)
The original question was about Windows GUI applications, created using Winforms, WPF, and other Windows-only technologies. Those applications do not use X Windows. WSL2 is a Linux kernel, running multiple containers or “distros”, each with a Linux userland. The applications that you run on it are Linux apps, which can use X.
To get any X-windows app to work from inside a container, while on Windows:
TL;DR version:
Install an X Server on Windows (MobaXTerm is a good choice) and start it.
Run an X app inside a container, and set the DISPLAY environment variable to <your desktop ip address>:0.0. Note: localhost or 127.0.0.1 will not do; it needs to be the actual IP address of your desktop. Example:
docker run --name ff1 --env DISPLAY=<your desktop ip>:0.0 jess/firefox
Full explanation:
In current WSL2, you can run GUI Linux applications. This works as follows:
Each “distribution” that you run in WSL is a container (not docker container) on a lightweight Linux VM. Each distro has a Linux userland, like ubuntu or debian. All of them share the same IP address, and are referred to as user distributions.
There is always an additional distro, which is referred to as the system distribution. This has the Microsoft Azure Linux(CBL-Mariner) userland, and runs the Weston Wayland compositor with with XWayland and an RDP backend. When you run a GUI app in any user distribution, it talks to Weston via the Wayland socket, or XWayland via the X socket (which talks to Weston). Weston renders the app via RDP, which is shown on your Windows desktop by a copy of mstsc.exe that is already running there. So, an X server is not needed on Windows itself.
Docker desktop usually is one more user distribution(with what looks like the Linuxkit userland). All containers run in that.
Containers, being isolated, cannot directly access the Wayland running on the system distro. And Wayland cannot be remoted.
So, we need to run an independent X server on our Windows desktop, and set the DISPLAY environment variable in a container to point to that using our desktop’s IP address. The X application inside the container will send the X instructions directly to our desktop, bypassing the system distro completely.
Great answer! Your “full explanation” finally explained why all my attempts to connect to the WSL X-Windows server failed.
I installed MobaXTerm and was frustrated as xclock never connected from inside my container. Then I discovered xclock on my Mac also failed (with DISPLAY=(windows11 Ip address):0). By chance I noticed that MobaXTerm was serving DISPLAY=:1 – changing to :1 lets both the container and my Mac connect to the MobaXTerm X-windows server (it prompted to permit a foreign connection, and has a setting to always permit them). As the WSL X-server is :0, I’m guessing that MobaXTerm does not want to step on that, so it uses :1.