[Mono-list] Mono, Windows Forms, and Headless operation

[Miguel de Icaza]

Hello,

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
ThreadPool?

Miguel

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
> error:
>
> 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?”
>
> Cheers.
> — — —
> Glover E. George
> Computer Scientist
> Information Technology Laboratory
> US Army Engineer Research and Development Center
> Vicksburg, MS 39180
> 601-634-4730
>
>
> _______________________________________________
> Mono-list maillist  -  Mono-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-list/attachments/20160208/7963e758/attachment.html>