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.geo...@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@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-list > >
_______________________________________________ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list