[Mono-list] Mono, Windows Forms, and Headless operation
George, Glover E ERDC-RDE-ITL-MS
Glover.E.George at erdc.dren.mil
Thu Jan 7 21:24:14 UTC 2016
We’re currently porting a Windows Forms Application to Mono, and have generally had great success. However, we have now hit a critical decision point, and were hoping for some guidance on the best route forward. If we don’t have X11, mono fails to run Windows Forms code with the following error:
From: System.Windows.Forms, at: Void .ctor(), Error Message: The type initializer for 'System.Windows.Forms.WindowsFormsSynchronizationContext' threw an exception.
The main question I had for the Mono list is this. Is it possible to have mono run Windows Forms code without trying to open X11 (I.e. headless mode)? What triggers mono to request an X11 display? Is it the project type? Is it the call to an object that inherits from a Windows Forms control? I don’t need to see the form, but if I’m using BackgroundWorkers, I need the form's event handler, don’t I?
Requirements dictate that make every attempt possible to keep a single code base. I.e., either if’s or #ifdefs if different code needs to run on Linux than on Windows.
The code uses multiple concurrent BackgroundWorkers (it’s a .net 2.0 app, and we currently don’t have permission to move it to 4.0 and thread pools) that process data in parallel. We’re trying to run this code on a large Linux-based HPC system that uses a batch (PBS) queueing system. The problem is that we do not have X11 available on the compute nodes (well, at least not unless we’re in interactive mode, and that’s against the requirements). There is a large amount of logic that is tied into using BackgroundWorkers, and those seem to require a visible form to provide an event loop to handle events generated by the BackgroundWorkers. Essentially, this app was designed to only be run interactively, but now we’re both parallelizing it, as well as giving it a headless option (I.e. if a command line option is given, we’re running with no GUI).
1. We tried creating a Windows Console app in Visual Studio, essentially a driver, that then instantiated the the forms and ran them. Although nothing is shown on the screen, it still required us to use X11. giving the error at the top of this message.
2. We tried just not using BackgroundWorkers. This meant the code was single threaded, but it still relies on logic in the Windows forms. We could move this logic to classes that don’t have anything to do with Windows Forms, but now we have two code bases, essentially. However, it still fails even though we don’t display anything on screen, we get the error at the top of this message.
3. Xvfb. This works on local VM’s, but not on our cluster, which we don’t have admin rights to (it’s not installed). There is a possibility that we could install X11-Xvfb from source, but this seems overkill.
4. Worst case option - remove all background worker logic, and change it to just use C# threads. REALLY don’t want to do this if we don’t have to.
I know this may be confusing, and if so, please feel free to ask for clarifications, or even just to say “Why would you want to do that?”
— — —
Glover E. George
Information Technology Laboratory
US Army Engineer Research and Development Center
Vicksburg, MS 39180
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mono-list