[Mono-list] Mono, Windows Forms, and Headless operation
Miguel de Icaza
miguel at xamarin.com
Tue Feb 9 03:19:51 UTC 2016
ThreadPools are available on .NET 2.0, just not the fancier TPL-based ones.
Perhaps you could consider replacing that bit of code with using the
On Thu, Jan 7, 2016 at 4:24 PM, George, Glover E ERDC-RDE-ITL-MS <
Glover.E.George at erdc.dren.mil> wrote:
> Hi all,
> 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
> From: System.Windows.Forms, at: Void .ctor(), Error Message: The type
> initializer for 'System.Windows.Forms.WindowsFormsSynchronizationContext'
> threw an exception.
> Question First:
> 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?
> Details Last:
> 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
> Computer Scientist
> Information Technology Laboratory
> US Army Engineer Research and Development Center
> Vicksburg, MS 39180
> Mono-list maillist - Mono-list at lists.ximian.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mono-list