Re: [Mono-list] Mono, Windows Forms, and Headless operation
My apologies, but I actually hit send before I was done. The BackgroundWorker works without Windows Forms, but I need a message pump provided by an actual form or manually calling Application.Run, both of which trigger the XPlatUI subsystem in Mono to look for an actual X11 display. My initial thought was, can’t I just put a dummy class in there which replaces XPlatUIX11 stuff, but it seems that the code might be tightly coupled to the X11 specific code (it seems to be non-trivial to do this). I had hope to speak to the author of this code, Peter Bartok, but it seems his been out of the loop for a while and I can’t find current contact information for him. That being said, we’re now going to do it the hard way. We have a small time extension, so we’re going to start removing any non-windows logic from the forms code, stick it in is own class, and go the route of ThreadPools. The previous concern I had with the fact that many of the hundred or so classes have [Attributes] related to property grid editing doesn’t seem to trigger any X11 code in mono since they’re from System.ComponentModel (as is BackgroundWorker). It’s the pesky message pump that’s causing the problem. I admit, it is slightly unusual to want to run a Windows Forms code headless, but it’s what fell in our lap. Cheers. — — — Glover E. George Computer Scientist Information Technology Laboratory US Army Engineer Research and Development Center Vicksburg, MS 39180 601-634-4730 From: Glover George mailto:glover.e.geo...@erdc.dren.mil>> Date: Tuesday, February 9, 2016 at 10:38 AM To: Miguel de Icaza mailto:mig...@xamarin.com>> Cc: "mono-list@lists.ximian.com<mailto:mono-list@lists.ximian.com>" mailto:mono-list@lists.ximian.com>> Subject: Re: [Mono-list] Mono, Windows Forms, and Headless operation Hi Miguel, Thanks for the response. After digging into the mono source a bit, as well as writing a few test programs, I’ve discovered a bit more. The Background worker threads actually work without Windows Forms. — — — Glover E. George Computer Scientist Information Technology Laboratory US Army Engineer Research and Development Center Vicksburg, MS 39180 601-634-4730 From: Miguel de Icaza mailto:mig...@xamarin.com>> Date: Monday, February 8, 2016 at 9:19 PM To: Glover George mailto:glover.e.geo...@erdc.dren.mil>> Cc: "mono-list@lists.ximian.com<mailto:mono-list@lists.ximian.com>" mailto:mono-list@lists.ximian.com>> Subject: Re: [Mono-list] Mono, Windows Forms, and Headless operation 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 mailto: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. Altho
Re: [Mono-list] Mono, Windows Forms, and Headless operation
Hi Miguel, Thanks for the response. After digging into the mono source a bit, as well as writing a few test programs, I’ve discovered a bit more. The Background worker threads actually work without Windows Forms. — — — Glover E. George Computer Scientist Information Technology Laboratory US Army Engineer Research and Development Center Vicksburg, MS 39180 601-634-4730 From: Miguel de Icaza mailto:mig...@xamarin.com>> Date: Monday, February 8, 2016 at 9:19 PM To: Glover George mailto:glover.e.geo...@erdc.dren.mil>> Cc: "mono-list@lists.ximian.com<mailto:mono-list@lists.ximian.com>" mailto:mono-list@lists.ximian.com>> Subject: Re: [Mono-list] Mono, Windows Forms, and Headless operation 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 mailto: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<mailto:Mono-list@lists.ximian.com> Blockedhttp://lists.ximian.com/mailman/listinfo/mono-listBlocked ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono, Windows Forms, and Headless operation
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
Re: [Mono-list] Mono, Windows Forms, and Headless operation
Hey George
In a couple of places you mention you don't want to see the GUI and only
needed background workers? u think using normal threads will do the trick.
You can do everything and more that the background wonder does. Check
http://www.albahari.com/threading/ for more help.
Cheers
Mladen
On Saturday, 9 January 2016, George, Glover E ERDC-RDE-ITL-MS <
glover.e.geo...@erdc.dren.mil> wrote:
> Thanks Jordan.
>
> It turns out, I may have been conflating two problems into one. The fact
> that I needed to show the windows form was because I needed a message loop
> to process the BackgroundWorker¹s events. Turns out I can just call
> Application.Run() with no parameter, and it will cause the UI thread to
> start a message loop that works fine.
>
> The real problem is that it still seems as though mono requires X11 for
> Windows Forms apps. So I created a new project from scratch to test this
> theory. It is a very simple app. It¹s a simple form with a button
> (runButton) and a progress bar (progressBar1) (Designer code is left out
> due to space).
>
> PROGRAM.CS
> static class Program
> {
> ///
> /// The main entry point for the application.
> ///
> [STAThread]
> static void Main()
> {
> // Instantiate the Main Form
> Form frm = new Form1();
> Application.Run();
> }
> }
>
>
> #FORM1.cs
> public partial class Form1 : Form
> {
> public Form1()
> {
> InitializeComponent();
> runButton_Click(this,null);
> }
>
> private void runButton_Click(object sender, EventArgs e)
> {
> BackgroundWorker worker = new BackgroundWorker();
> worker.WorkerReportsProgress = true;
> worker.DoWork += DoWork;
> worker.ProgressChanged += ProgressChanged;
> worker.RunWorkerCompleted += WorkerCompleted;
> worker.RunWorkerAsync(worker);
> }
>
> public void DoWork(object sender, EventArgs e)
> {
> var worker = sender as BackgroundWorker;
> for (int i = 0; i < 100; i++)
> {
> Thread.Sleep(100);
> worker.ReportProgress(i);
> }
> }
>
> public void ProgressChanged(object sender, ProgressChangedEventArgs e)
> {
> progressBar1.Value = e.ProgressPercentage;
> }
>
> public void WorkerCompleted(object sender, EventArgs e)
> {
> MessageBox.Show("I'm done!!!");
> Application.Exit();
> }
> }
>
>
> This program runs perfectly well without displaying anything so long as
> DISPLAY is set to a valid X11 Display (:0). However, if I unset DISPLAY
> (export DISPLAY=), then I get the following error. Note, this is similar
> to the error I previously posted, but the stack trace and error message is
> a bit more detailed (don¹t know why yet):
>
>
> Unhandled Exception:
> System.TypeInitializationException: The type initializer for
> 'System.Windows.Forms.WindowsFormsSynchronizationContext' threw an
> exception. ---> System.TypeInitializationException: The type initializer
> for 'System.Windows.Forms.XplatUI' threw an exception. --->
> System.ArgumentNullException: Could not open display (X-Server required.
> Check your DISPLAY environment variable)
> Parameter name: Display
> at System.Windows.Forms.XplatUIX11.SetDisplay (IntPtr display_handle)
> <0x4100b560 + 0x00b9b> in :0
> at System.Windows.Forms.XplatUIX11..ctor () <0x41009890 + 0x001df> in
> :0
> at System.Windows.Forms.XplatUIX11.GetInstance () <0x410096c0 + 0x0005b>
> in :0
> at System.Windows.Forms.XplatUI..cctor () <0x41009390 + 0x00137> in
> :0
> --- End of inner exception stack trace ---
> at System.Windows.Forms.Theme.get_MenuAccessKeysUnderlined ()
> <0x41009340 + 0xb> in :0
> at System.Windows.Forms.SystemInformation.get_MenuAccessKeysUnderlined
> () <0x41004790 + 0x00017> in :0
> at System.Windows.Forms.Control..ctor () <0x410033b0 + 0x00243> in
> :0
> at (wrapper remoting-invoke-with-check)
> System.Windows.Forms.Control:.ctor ()
> at System.Windows.Forms.WindowsFormsSynchronizationContext..cctor ()
> <0x410046c0 + 0x0001f> in :0
> --- End of inner exception stack trace ---
> at System.Windows.Forms.Control..ctor () <0x410033b0 + 0x00053> in
> :0
> at System.Windows.Forms.ScrollableControl..ctor () <0x41002e40 +
> 0xf> in :0
> at System.Windows.Forms.ContainerControl..ctor () <0x41002cb0 + 0x00027>
> in :0
> at System.Windows.Forms.Form..ctor () <0x41002430 + 0x000bb> in
> :0
> at test2.Form1..ctor () <0x4090 + 0x0001f> in :0
> at (wrapper remoting-invoke-with-check) test2.Form1:.ctor ()
> at test2.Program.Main () <0x40fffd90 + 0x0001b> in :0
> [ERROR] FATAL UNHANDLED EXCEPTION: System.TypeInitializationException: The
> type initializer for
> 'System.Windows.Forms.WindowsFormsSynchronizationContext' threw an
> exception. ---> System.TypeInitializationException: The type initializer
> for 'System.Windows.Forms.XplatUI' threw an exception. --->
> System.ArgumentNullException: Could not open display (X-Server required.
> Check your DISPLAY environment variable)
> Parameter name: Disp
Re: [Mono-list] Mono, Windows Forms, and Headless operation
Thanks Jordan.
It turns out, I may have been conflating two problems into one. The fact
that I needed to show the windows form was because I needed a message loop
to process the BackgroundWorker¹s events. Turns out I can just call
Application.Run() with no parameter, and it will cause the UI thread to
start a message loop that works fine.
The real problem is that it still seems as though mono requires X11 for
Windows Forms apps. So I created a new project from scratch to test this
theory. It is a very simple app. It¹s a simple form with a button
(runButton) and a progress bar (progressBar1) (Designer code is left out
due to space).
PROGRAM.CS
static class Program
{
///
/// The main entry point for the application.
///
[STAThread]
static void Main()
{
// Instantiate the Main Form
Form frm = new Form1();
Application.Run();
}
}
#FORM1.cs
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
runButton_Click(this,null);
}
private void runButton_Click(object sender, EventArgs e)
{
BackgroundWorker worker = new BackgroundWorker();
worker.WorkerReportsProgress = true;
worker.DoWork += DoWork;
worker.ProgressChanged += ProgressChanged;
worker.RunWorkerCompleted += WorkerCompleted;
worker.RunWorkerAsync(worker);
}
public void DoWork(object sender, EventArgs e)
{
var worker = sender as BackgroundWorker;
for (int i = 0; i < 100; i++)
{
Thread.Sleep(100);
worker.ReportProgress(i);
}
}
public void ProgressChanged(object sender, ProgressChangedEventArgs e)
{
progressBar1.Value = e.ProgressPercentage;
}
public void WorkerCompleted(object sender, EventArgs e)
{
MessageBox.Show("I'm done!!!");
Application.Exit();
}
}
This program runs perfectly well without displaying anything so long as
DISPLAY is set to a valid X11 Display (:0). However, if I unset DISPLAY
(export DISPLAY=), then I get the following error. Note, this is similar
to the error I previously posted, but the stack trace and error message is
a bit more detailed (don¹t know why yet):
Unhandled Exception:
System.TypeInitializationException: The type initializer for
'System.Windows.Forms.WindowsFormsSynchronizationContext' threw an
exception. ---> System.TypeInitializationException: The type initializer
for 'System.Windows.Forms.XplatUI' threw an exception. --->
System.ArgumentNullException: Could not open display (X-Server required.
Check your DISPLAY environment variable)
Parameter name: Display
at System.Windows.Forms.XplatUIX11.SetDisplay (IntPtr display_handle)
<0x4100b560 + 0x00b9b> in :0
at System.Windows.Forms.XplatUIX11..ctor () <0x41009890 + 0x001df> in
:0
at System.Windows.Forms.XplatUIX11.GetInstance () <0x410096c0 + 0x0005b>
in :0
at System.Windows.Forms.XplatUI..cctor () <0x41009390 + 0x00137> in
:0
--- End of inner exception stack trace ---
at System.Windows.Forms.Theme.get_MenuAccessKeysUnderlined ()
<0x41009340 + 0xb> in :0
at System.Windows.Forms.SystemInformation.get_MenuAccessKeysUnderlined
() <0x41004790 + 0x00017> in :0
at System.Windows.Forms.Control..ctor () <0x410033b0 + 0x00243> in
:0
at (wrapper remoting-invoke-with-check)
System.Windows.Forms.Control:.ctor ()
at System.Windows.Forms.WindowsFormsSynchronizationContext..cctor ()
<0x410046c0 + 0x0001f> in :0
--- End of inner exception stack trace ---
at System.Windows.Forms.Control..ctor () <0x410033b0 + 0x00053> in
:0
at System.Windows.Forms.ScrollableControl..ctor () <0x41002e40 +
0xf> in :0
at System.Windows.Forms.ContainerControl..ctor () <0x41002cb0 + 0x00027>
in :0
at System.Windows.Forms.Form..ctor () <0x41002430 + 0x000bb> in
:0
at test2.Form1..ctor () <0x4090 + 0x0001f> in :0
at (wrapper remoting-invoke-with-check) test2.Form1:.ctor ()
at test2.Program.Main () <0x40fffd90 + 0x0001b> in :0
[ERROR] FATAL UNHANDLED EXCEPTION: System.TypeInitializationException: The
type initializer for
'System.Windows.Forms.WindowsFormsSynchronizationContext' threw an
exception. ---> System.TypeInitializationException: The type initializer
for 'System.Windows.Forms.XplatUI' threw an exception. --->
System.ArgumentNullException: Could not open display (X-Server required.
Check your DISPLAY environment variable)
Parameter name: Display
at System.Windows.Forms.XplatUIX11.SetDisplay (IntPtr display_handle)
<0x4100b560 + 0x00b9b> in :0
at System.Windows.Forms.XplatUIX11..ctor () <0x41009890 + 0x001df> in
:0
at System.Windows.Forms.XplatUIX11.GetInstance () <0x410096c0 + 0x0005b>
in :0
at System.Windows.Forms.XplatUI..cctor () <0x41009390 + 0x00137> in
:0
--- End of inner exception stack trace ---
at System.Windows.Forms.Theme.get_MenuAccessKeysUnderlined ()
<0x41009340 + 0xb> in :0
at System.Windows.Forms.SystemInformation.get_MenuAccessKeysUnderlined
() <0x41004790 + 0x00017> in :0
at System.Windows.Forms.Control..ctor () <0x410033b0 + 0x00
Re: [Mono-list] Mono, Windows Forms, and Headless operation
I think the advice would generally be: 1. Yes you can absolutely write a Console Application, which works perfectly cross-platform, and does not need any WinForms or X11. (Right click your solution, new project, Console Application). It's better to create a new project than to convert an existing WinForms project, unless you know all the details of what's different between the two types of projects. They launch differently, in different thread compartments, and some stuff like that - it's not as simple as merely removing the System.Windows.Forms reference. Which brings me to the second point... 2. You really should separate your business logic from the GUI code. 3. In general, you should not expect WinForms to work well on anything other than windows. If you need a GUI for other platforms, design a new one, or use a cross-platform GUI toolkit such as Eto.Forms. If you don't need a GUI... Then separate the WinForms GUI code from the non-GUI code, so you can build your non-windows project independently of WinForms. Really, the core logic should be moved to its own assembly, so the winforms project and console project can both reference it. There is *some* support for WinForms on non-windows platforms. Rarely does it ever work well - nobody on a mac or linux wants windows that look like WinForms - and that's if it works at all. (Lots of times it's straight up nonfunctional). Even if it works perfectly, nobody wants to be dependent on launching X11 on a mac, and it's only *sometimes* acceptable on linux. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono, Windows Forms, and Headless operation
On 07.01.2016 22:24, George, Glover E ERDC-RDE-ITL-MS 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? BackgroundWorker does not depend upon System.Windows.Forms, i.e. it can use it headless. The exception you're experiencing is caused by the synchronization context set and used by WinForms. Supposing that you don't need any kind of synchronization, you may want to replace the synchronization context with a simple one. I don't know if the most simple one (System.Threading.SynchronizationContext) would be enough or if you have to subclass it. Have a look at its sources and at System.Windows.Forms.WindowsFormsSynchronizationContext. Robert ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono, Windows Forms, and Headless operation
Again, I agree with the separation of business logic from the GUI. In fact, on mono, I never want to see the GUI. It¹s due to the fact that my parallelism relies on multiple concurrent BackgroundWorkers. I¹m restricted to .net 2.0 , nothing later. So I don¹t have the TPL available. I have BackgroundWorkers, Threads, and Threadpool. As I understand it, Threadpools don¹t have a way to know when they are finished (at least, not directly). Perhaps I misunderstand. BackgroundWorkers are simple, and are performing their function perfectly on Mono, so long as X is there. The only option left is directly using Threads. So to be clear, the only reason I wanted Windows Forms on Mono is to use BackgroundWorker because it¹s simple and it works. ‹ ‹ ‹ Glover E. George Computer Scientist Information Technology Laboratory US Army Engineer Research and Development Center Vicksburg, MS 39180 601-634-4730 On 1/8/16, 10:09 AM, "Edward Ned Harvey (mono)" wrote: >I think the advice would generally be: > >1. Yes you can absolutely write a Console Application, which works >perfectly cross-platform, and does not need any WinForms or X11. (Right >click your solution, new project, Console Application). It's better to >create a new project than to convert an existing WinForms project, unless >you know all the details of what's different between the two types of >projects. They launch differently, in different thread compartments, and >some stuff like that - it's not as simple as merely removing the >System.Windows.Forms reference. Which brings me to the second point... >2. You really should separate your business logic from the GUI code. >3. In general, you should not expect WinForms to work well on anything >other than windows. If you need a GUI for other platforms, design a new >one, or use a cross-platform GUI toolkit such as Eto.Forms. If you don't >need a GUI... Then separate the WinForms GUI code from the non-GUI code, >so you can build your non-windows project independently of WinForms. > >Really, the core logic should be moved to its own assembly, so the >winforms project and console project can both reference it. > >There is *some* support for WinForms on non-windows platforms. Rarely >does it ever work well - nobody on a mac or linux wants windows that look >like WinForms - and that's if it works at all. (Lots of times it's >straight up nonfunctional). Even if it works perfectly, nobody wants to >be dependent on launching X11 on a mac, and it's only *sometimes* >acceptable on linux. > ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono, Windows Forms, and Headless operation
Hi Timotheus, Thanks for your reply. Unfortunately, changing from WinExe to Exe doesn¹t help as it still wants an X Display. Also, most of the business logic is separate from the gui . However, the multithreading uses Background Workers, which to my knowledge, requires an event loop to handle the ProgressChanged and WorkerCompleted events. If I don¹t display the form, the Progress Changed event is raised, but the UI thread doesn¹t handle it. So if I drive the business logic without any forms (which would be nice), I¹d be forced to change the implementation to using C# threads instead of Background Workers. This isn¹t entirely impossible, but will take much longer. I have three weeks (otherwise, I wouldn¹t try to bother the list, I¹d work it out myself :D). Perhaps there are generic Event Loops in C# that could listen for events from the BackgroundWorkers, but I¹ve yet to find them. Note: This isn¹t exactly a problem with Mono. If I create and display the form, from which the Background Workers are created and run, it works fine in both Mono and Windows. If I create the form but do not display it (insatiate, initialize the form, and instantiate several background workers), the UI thread terminates before the Background Workers in BOTH Mono and Windows. The question is really a matter of what Makes Mono require X? Is it the project type (doesn¹t seem to be), or is it the fact that I¹m creating objects from the Forms object hierarchy? Also, is there a cheap, dirty trick to just not attempt to connect to X, yet still have the logic run? It¹s looking more and more inevitable that if I wanted a multithreaded C# app under mono, and require it to run without X, BackgroundWorker isn¹t a solution. If that¹s the case, I guess I can accept that. ‹ ‹ ‹ Glover E. George Computer Scientist Information Technology Laboratory US Army Engineer Research and Development Center Vicksburg, MS 39180 601-634-4730 On 1/8/16, 1:13 AM, "mono-list-boun...@lists.ximian.com on behalf of Timotheus Pokorra" wrote: >Hello George, > >> 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? > >You should try to modify the project type, ie OutputType in the csproj >file, WinExe vs Exe. > >> 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?² > >I wonder if you could cleanly separate the business logic from the >gui. Then you can have a dll with the business logic, which you can >reference from your winforms forms, but also from your console >application. > >hope this helps, > Timotheus >___ >Mono-list maillist - Mono-list@lists.ximian.com >Blockedhttp://lists.ximian.com/mailman/listinfo/mono-listBlocked ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono, Windows Forms, and Headless operation
Hello George, > 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? You should try to modify the project type, ie OutputType in the csproj file, WinExe vs Exe. > 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?” I wonder if you could cleanly separate the business logic from the gui. Then you can have a dll with the business logic, which you can reference from your winforms forms, but also from your console application. hope this helps, Timotheus ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono, Windows Forms, and Headless operation
Hello Netgear, > -Mono(Mono.Mac not Xamarin.Mac) support is non existent.You can see this > forum is full of spam and rarely someone replies. I don't think the original poster is refering to Mono.Mac? X11 is not OSX ;) And the mono list itself is quite clean from spam. You are using the nabble interface, and that seems pretty bad with spam piling up. Fortunately those messages don't get through to the mailing list. for example see the archive from December: http://lists.ximian.com/pipermail/mono-list/2015-December/thread.html And there have been replies to messages. Not to every message, because some issues are complicated. Asking on the IRC #mono channel sometimes helps as well. Timotheus ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono, Windows Forms, and Headless operation
I have been trying to port my windows winforms app to Mac.I have managed to port it successfully by replacing winforms with gtk#.Background worker has some issues when there was concurrent execution,i switched to threads ,threads gave some other issues so i switched back to background worker and ironed out the issues. The point i want to make is even if you manage to port the application the following problems exists which keeps you from proper deployment -If you are using System.Drawing then your app first launch in a new computer will take around 3 minutes.The user does not see any progress -Bundling Mono Runtime(Standalone app)- simply does not work properly.You need to write some custom script -Mono(Mono.Mac not Xamarin.Mac) support is non existent.You can see this forum is full of spam and rarely someone replies. I have done all the hardwork,including the tons of workarounds for the buggy IDE which wasted lots of my time.Finally im here unable to properly deploy my app,because MONO is broken(if you go the gtk or the winforms way) If you want to use Mono and want 'support' and a thing that runs.You can build a Native UI using cocoa and use c# code. Just sharing :) - -- View this message in context: http://mono.1490590.n4.nabble.com/Mono-Windows-Forms-and-Headless-operation-tp4667273p4667275.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Mono, Windows Forms, and Headless operation
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
Re: [Mono-list] mono Windows VS 2003 Web Developer - Recommended Dev. Env. Configuration
Nate Chadwick wrote: > Hi I have been struggling in the setup of a sane development > environment as a mono user. Here is what I have gleaned from various > correspondence, google, and practical use this week. Does this jive > with what other Visual Studio developers migrating to mono are using? > > - > Web Developer Configuration > - > > Development System > > Windows XP (32-bit) > Cygwin (latest release version with build tools and openssh/subversion, > gtk/x?) > mono combined installer package (latest release) > monoLaunch > vsprj2make > TortoiseSVN > Visual Studio 2003 > IIS 6.0 > Front Page Server Extensions 2002 > VMWare 5.5 > > Key Libraries > > log4net - mono 1.0 target > nant - latest 1.1 target > nunit - latest 1.1 target > > - > Server Test VM on VMWare > - > Suse 10 (stable) (or OpenSuse?) > Apache 2.2 > mono linux installer -(latest release with xsp/mod_mono) > ssh > vmwaretools > > Thanks, > -nate > That is a pretty good configuration. Congratulations :). I would only add one more thing just because ever since the introduction of GLib 2.8.x there has been some problems with xsp on Win32 -- I am pretty sure it is related to GLib more than it is to xsp. I would also add something like mono 1.1.10 found here (in addition to the latest Mono Combined installer you may already have): http://forge.novell.com/modules/xfcontent/downloads.php/monowin32/Mono%20Win32%20Combined%20Installer/v1.1.10/ You could opt just to install mono and xsp on that one. This is would be just to test your web projects (asp.net). Best of luck, Paco ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] mono Windows VS 2003 Web Developer - Recommended Dev. Env. Configuration
Hi I have been struggling in the setup of a sane development environment as a mono user. Here is what I have gleaned from various correspondence, google, and practical use this week. Does this jive with what other Visual Studio developers migrating to mono are using? - Web Developer Configuration - Development System Windows XP (32-bit) Cygwin (latest release version with build tools and openssh/subversion, gtk/x?) mono combined installer package (latest release) monoLaunch vsprj2make TortoiseSVN Visual Studio 2003 IIS 6.0 Front Page Server Extensions 2002 VMWare 5.5 Key Libraries log4net - mono 1.0 target nant - latest 1.1 target nunit - latest 1.1 target - Server Test VM on VMWare - Suse 10 (stable) (or OpenSuse?) Apache 2.2 mono linux installer -(latest release with xsp/mod_mono) ssh vmwaretools Thanks, -nate ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] Mono windows
Exactly, if you know something is needed provide it! Especially if it is not provided with shrink wrapped versions of the os. -Mark -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 04, 2004 4:35 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [Mono-list] Mono windows I agree totally with you but it's only a problem when building the thing. Installing from setups / red carpet works like a charm. I think this is the problem in general with makefiles. We really should have something better, but this would be a lot of work. For example, the thing shouldn't say "libgc 2.0.0.0 < 2.1.1.1, I do not like it, ERROR, I do not install for you"... In this new era it should be something like: "Dude, you didn't have the correct version of libgc, I installed a newer one for you my master". Ultimatly, this could be possible with a MSBuild-like clone. Eventually, we'll get there :). Greetz, -- Rob. > -Original Message- > From: Molenda, Mark P [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 04, 2004 4:20 PM > To: '[EMAIL PROTECTED]' > Subject: Re: [Mono-list] Mono windows > > Joe, > You are not alone. Even on stock builds of Linux there are many > conflicts and problems. If you load anything outside of the base > product. Your suggestion of putting the working dll's in a zip or > installer would work the same as my suggestion to move all the > libraries in one directory on Linux and set LD_LIBRARY_PATH to the > appropriate place to pick everything up. > This would allow users to work with little or no effort. Now I'm sure > someone will flame me for this but no one including the originator of > the project has explained to me why a 1.0 product does not load with > libraries and environments of supported distributions (i.e. Suse , > RedHat etc.) without major hassles. It seems there is a lot of work > to do on getting shrink wrapped versions Of major distributions ( > Windows XP is one ) to work with the full mono. > > > Message: 1 > Date: Tue, 03 Aug 2004 12:30:39 +0200 > Subject: Re: [Mono-list] Mono windows > From: Joe Ante <[EMAIL PROTECTED]> > To: MONO <[EMAIL PROTECTED]> > > HI, > > After trying to build mono on windows for 2 days using the help of a > unix guy, it still doesn=B9t work. > I tried everything from the windows build scripts to the > www.nullenvoid.com/wiki intro how to manually compile mono. To just > trying to figure out the error msgs myself. > I am getting problems like GCC hanging in monoburg.c, but mostly just > pkgconfig not finding libraries. > > I am desperate now. > Does anyone have a built mono install which includes the dll's and > librarie= s needed for embedding mono and wants to send it over? > > Or what if someone smart would just put the dll's into the windows > installer, wouldn=B9t that be like real cute. > > Joachim Ante > > > --__--__-- > > ___ > Mono-list maillist - [EMAIL PROTECTED] > http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] Mono windows
I agree totally with you but it's only a problem when building the thing. Installing from setups / red carpet works like a charm. I think this is the problem in general with makefiles. We really should have something better, but this would be a lot of work. For example, the thing shouldn't say "libgc 2.0.0.0 < 2.1.1.1, I do not like it, ERROR, I do not install for you"... In this new era it should be something like: "Dude, you didn't have the correct version of libgc, I installed a newer one for you my master". Ultimatly, this could be possible with a MSBuild-like clone. Eventually, we'll get there :). Greetz, -- Rob. > -Original Message- > From: Molenda, Mark P [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 04, 2004 4:20 PM > To: '[EMAIL PROTECTED]' > Subject: Re: [Mono-list] Mono windows > > Joe, > You are not alone. Even on stock builds of Linux there are many > conflicts > and problems. If you load anything outside of the base product. Your > suggestion of putting the working dll's in a zip or installer would work > the > same as my suggestion to move all the libraries in one directory on Linux > and set LD_LIBRARY_PATH to the appropriate place to pick everything up. > This would allow users to work with little or no effort. Now I'm sure > someone will flame me for this but no one including the originator of the > project has explained to me why a 1.0 product does not load with libraries > and environments of supported distributions (i.e. Suse , RedHat etc.) > without major hassles. It seems there is a lot of work to do on getting > shrink wrapped versions > Of major distributions ( Windows XP is one ) to work with the full mono. > > > Message: 1 > Date: Tue, 03 Aug 2004 12:30:39 +0200 > Subject: Re: [Mono-list] Mono windows > From: Joe Ante <[EMAIL PROTECTED]> > To: MONO <[EMAIL PROTECTED]> > > HI, > > After trying to build mono on windows for 2 days using the help of a unix > guy, it still doesn=B9t work. > I tried everything from the windows build scripts to the > www.nullenvoid.com/wiki intro how to manually compile mono. To just trying > to figure out the error msgs myself. > I am getting problems like GCC hanging in monoburg.c, but mostly just > pkgconfig not finding libraries. > > I am desperate now. > Does anyone have a built mono install which includes the dll's and > librarie= > s needed for embedding mono and wants to send it over? > > Or what if someone smart would just put the dll's into the windows > installer, wouldn=B9t that be like real cute. > > Joachim Ante > > > --__--__-- > > ___ > Mono-list maillist - [EMAIL PROTECTED] > http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono windows
Joe, You are not alone. Even on stock builds of Linux there are many conflicts and problems. If you load anything outside of the base product. Your suggestion of putting the working dll's in a zip or installer would work the same as my suggestion to move all the libraries in one directory on Linux and set LD_LIBRARY_PATH to the appropriate place to pick everything up. This would allow users to work with little or no effort. Now I'm sure someone will flame me for this but no one including the originator of the project has explained to me why a 1.0 product does not load with libraries and environments of supported distributions (i.e. Suse , RedHat etc.) without major hassles. It seems there is a lot of work to do on getting shrink wrapped versions Of major distributions ( Windows XP is one ) to work with the full mono. Message: 1 Date: Tue, 03 Aug 2004 12:30:39 +0200 Subject: Re: [Mono-list] Mono windows From: Joe Ante <[EMAIL PROTECTED]> To: MONO <[EMAIL PROTECTED]> HI, After trying to build mono on windows for 2 days using the help of a unix guy, it still doesn=B9t work. I tried everything from the windows build scripts to the www.nullenvoid.com/wiki intro how to manually compile mono. To just trying to figure out the error msgs myself. I am getting problems like GCC hanging in monoburg.c, but mostly just pkgconfig not finding libraries. I am desperate now. Does anyone have a built mono install which includes the dll's and librarie= s needed for embedding mono and wants to send it over? Or what if someone smart would just put the dll's into the windows installer, wouldn=B9t that be like real cute. Joachim Ante --__--__-- ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono windows genmdesc crash
Hi, The easiest way to solve this problem is to install XML::Parser. It is available from here: http://cygwin-ports.sourceforge.net/ Atsushi Eno Marko Suovula wrote: Same here, although with current CVS version it stops in (full Cygwin with Win2k): " perl ./make-opcodes-def.pl ./cil-opcodes.xml opcode.def.tmp Can't locate XML/Parser.pm in @INC (@INC contains: /usr/lib/perl5/5.8.2/cygwin-thread-multi-64int /usr/lib/perl5/5.8.2 /usr/lib/perl5/site_perl/5.8.2/cygwin-thread-multi-64int /usr/lib/perl5/site_perl /5.8.2 /usr/lib/perl5/site_perl .) at ./make-opcodes-def.pl line 16. BEGIN failed--compilation aborted at ./make-opcodes-def.pl line 16. " (the whole file can be found in http://www.sci.fi/~msuovula/temp/mono_build_20040804.txt) But the genmdesc seems to be the biggest problem. It has never worked for me, so if somebody could send me the cpu-pentium.h, cpu-amd64.h, cpu-g4.h, cpu-sparc.h, cpu-s390.h and cpu-s390x.h files I could see how far it would compile alter that. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] Mono windows genmdesc crash
Me, too. I'm stuck at the same point. I wanted to try to add reference counting so that finalizers can be called deterministically. This wouldn't work for cycles. The GC would still have to call finalizers in that case. Also, the GC would still be responsible for managing memory. I'd just like to know that, in the absence of cycles, my finalizers will be called as soon as the last reference is released. I'd still like to try to do that research (especially the performance impacts). I'd rather not have to build a linux box just to build mono. If you get an answer, please post it. I would also appreciate getting an answer, too. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono windows genmdesc crash
Same here, although with current CVS version it stops in (full Cygwin with Win2k): " perl ./make-opcodes-def.pl ./cil-opcodes.xml opcode.def.tmp Can't locate XML/Parser.pm in @INC (@INC contains: /usr/lib/perl5/5.8.2/cygwin-thread-multi-64int /usr/lib/perl5/5.8.2 /usr/lib/perl5/site_perl/5.8.2/cygwin-thread-multi-64int /usr/lib/perl5/site_perl /5.8.2 /usr/lib/perl5/site_perl .) at ./make-opcodes-def.pl line 16. BEGIN failed--compilation aborted at ./make-opcodes-def.pl line 16. " (the whole file can be found in http://www.sci.fi/~msuovula/temp/mono_build_20040804.txt) But the genmdesc seems to be the biggest problem. It has never worked for me, so if somebody could send me the cpu-pentium.h, cpu-amd64.h, cpu-g4.h, cpu-sparc.h, cpu-s390.h and cpu-s390x.h files I could see how far it would compile alter that. -- Marko - Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Tuesday, August 03, 2004 8:43 PM Subject: RE: [Mono-list] Mono windows genmdesc crash > Yup, here exactly the same... > > -- Rob. > > > -Original Message- > > From: Joe Ante [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, August 03, 2004 7:35 PM > > To: MONO > > Subject: [Mono-list] Mono windows genmdesc crash > > > > Hi, > > > > I am trying to build mono on windows at the moment. > > After two days we have gotten at least somewhere in the middle of the make > > process. > > But it currently hangs in genmdesc.exe. > > Either it crashes or it just loops with 100% CPU usage. > > > > "./genmdesc ./cpu-pentium.md cpu-pentium.h pentium_desc" > > gdb bt gives me the folling stacktrace for the place where it loops > > infinetely: > > > > #0 0x77e965d3 in Kernel32!GetPrivateProfileStructW () > > #1 0x1003e84 in getprogname () from /usr/bin/cygwin1.dll > > #2 0x00+af0d0 in ?? () > > > > Or: > > #0 0x77ea31c7 in Kenral32!GetAtomNameA () > > > > Any ideas, how to not make genmdesc crash? > > (Another person mailed me that he also crashes inside genmdesc) > > > > Joachim Ante > > > > ___ > > Mono-list maillist - [EMAIL PROTECTED] > > http://lists.ximian.com/mailman/listinfo/mono-list > ___ > Mono-list maillist - [EMAIL PROTECTED] > http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] Mono windows genmdesc crash
Yup, here exactly the same... -- Rob. > -Original Message- > From: Joe Ante [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 03, 2004 7:35 PM > To: MONO > Subject: [Mono-list] Mono windows genmdesc crash > > Hi, > > I am trying to build mono on windows at the moment. > After two days we have gotten at least somewhere in the middle of the make > process. > But it currently hangs in genmdesc.exe. > Either it crashes or it just loops with 100% CPU usage. > > "./genmdesc ./cpu-pentium.md cpu-pentium.h pentium_desc" > gdb bt gives me the folling stacktrace for the place where it loops > infinetely: > > #0 0x77e965d3 in Kernel32!GetPrivateProfileStructW () > #1 0x1003e84 in getprogname () from /usr/bin/cygwin1.dll > #2 0x00+af0d0 in ?? () > > Or: > #0 0x77ea31c7 in Kenral32!GetAtomNameA () > > Any ideas, how to not make genmdesc crash? > (Another person mailed me that he also crashes inside genmdesc) > > Joachim Ante > > ___ > Mono-list maillist - [EMAIL PROTECTED] > http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Mono windows genmdesc crash
Hi, I am trying to build mono on windows at the moment. After two days we have gotten at least somewhere in the middle of the make process. But it currently hangs in genmdesc.exe. Either it crashes or it just loops with 100% CPU usage. "./genmdesc ./cpu-pentium.md cpu-pentium.h pentium_desc" gdb bt gives me the folling stacktrace for the place where it loops infinetely: #0 0x77e965d3 in Kernel32!GetPrivateProfileStructW () #1 0x1003e84 in getprogname () from /usr/bin/cygwin1.dll #2 0x00+af0d0 in ?? () Or: #0 0x77ea31c7 in Kenral32!GetAtomNameA () Any ideas, how to not make genmdesc crash? (Another person mailed me that he also crashes inside genmdesc) Joachim Ante ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono windows
> As posted earlier in the discussion list: > > http://forge.novell.com/modules/xfmod/project/showfiles.php?group_id=1395&rel > ease_id=1945&dl=4409 > > See link for a download for a mono 1.0 installer for windows. Hi Jonathan, Thanks for the quick response. I downloaded, uninstalled the old mono installation and installed the installer you linked to. Unfortunately it does not include the mono runtime as an dll which is necessary to embed mono. Or am I on a wrong track here? (I want the windows equivalent of libmono.0.0.0.dylib on mac os x. So I can link against it and embed mono in my c application.) Joe Ante ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] Mono windows
As posted earlier in the discussion list: http://forge.novell.com/modules/xfmod/project/showfiles.php?group_id=1395&rel ease_id=1945&dl=4409 See link for a download for a mono 1.0 installer for windows. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joe Ante Sent: Tuesday, August 03, 2004 11:31 AM To: MONO Subject: Re: [Mono-list] Mono windows HI, After trying to build mono on windows for 2 days using the help of a unix guy, it still doesn¹t work. I tried everything from the windows build scripts to the www.nullenvoid.com/wiki intro how to manually compile mono. To just trying to figure out the error msgs myself. I am getting problems like GCC hanging in monoburg.c, but mostly just pkgconfig not finding libraries. I am desperate now. Does anyone have a built mono install which includes the dll's and libraries needed for embedding mono and wants to send it over? Or what if someone smart would just put the dll's into the windows installer, wouldn¹t that be like real cute. Joachim Ante ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list This email may contain information which is privileged or confidential. If you are not the intended recipient of this email, please notify the sender immediately and delete it without reading, copying, storing, forwarding or disclosing its contents to any other person Thank you Check us out at http://www.btsyntegra.com ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono windows
HI, After trying to build mono on windows for 2 days using the help of a unix guy, it still doesn¹t work. I tried everything from the windows build scripts to the www.nullenvoid.com/wiki intro how to manually compile mono. To just trying to figure out the error msgs myself. I am getting problems like GCC hanging in monoburg.c, but mostly just pkgconfig not finding libraries. I am desperate now. Does anyone have a built mono install which includes the dll's and libraries needed for embedding mono and wants to send it over? Or what if someone smart would just put the dll's into the windows installer, wouldn¹t that be like real cute. Joachim Ante ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono windows
> Hi, > > Is there any reason for not having a windows installer which includes the > dll's necessary for embedding mono? > > > I tried building mono using the mono-build-win32.sh script but it failed: > > Installing glib... > /usr/local/bin/mono-build-w32.sh: line 120: [: too many arguments > /usr/local/bin/mono-build-w32.sh: line 126: [: too many arguments > /usr/local/bin/mono-build-w32.sh: line 105: [: too many arguments > ... Btw. the install script fails because the place where I wanted to install mono contains space characters and the sh scripts doesn't have the correct quotes around its variables eg. In the install package function. Also at the very moment the go-mono.com server is down and the libraries the script tries to download are on that server... Joachim Ante ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Mono windows
Hi, Is there any reason for not having a windows installer which includes the dll's necessary for embedding mono? I tried building mono using the mono-build-win32.sh script but it failed: Installing glib... /usr/local/bin/mono-build-w32.sh: line 120: [: too many arguments /usr/local/bin/mono-build-w32.sh: line 126: [: too many arguments /usr/local/bin/mono-build-w32.sh: line 105: [: too many arguments ... Joachim Ante ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] mono+windows
En/na José Francisco Palma Soto ha escrit: When I try to install mono in windows appear this message: Updating mono Logging into CVS server. Anonymous CVS password is probably empty ./mono-build-w32.sh: line 45: cvs: command not found Wath can I Do? Have a look to: http://216.239.59.104/search?q=cache:vhx6l7AIhK8J:monoevo.sourceforge.net/mono-windows/mono-beginning-windows/t1.html+Mono+for+beginners&hl=en&ie=UTF-8 You will find full instructions of how to install and use Mono under win32. Best Regards, Jordi, Note: Sorry but the original document is off-line, use Google's cached copy until is fixed. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] mono+windows
You need to install the cvs package through cygwin. Run the cygwin setup tool and add cvs. I think it is under developer tools. You will also need make, auto* and probably a few other development packages. Jackson On Thu, 2004-02-12 at 17:23, José Francisco Palma Soto wrote: > When I try to install mono in windows appear this message: > > Updating mono > Logging into CVS server. Anonymous CVS password is probably empty > ./mono-build-w32.sh: line 45: cvs: command not found > > Wath can I Do? > > _ > Ãnete al mayor servicio mundial de correo electrónico: > http://www.hotmail.com > > ___ > Mono-list maillist - [EMAIL PROTECTED] > http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] mono+windows
When I try to install mono in windows appear this message: Updating mono Logging into CVS server. Anonymous CVS password is probably empty ./mono-build-w32.sh: line 45: cvs: command not found Wath can I Do? _ Únete al mayor servicio mundial de correo electrónico: http://www.hotmail.com ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] Mono Windows/Cygwin Repeatable Build Process
I think there is a combination of reasons, but yes, the mono-build-w32.sh rarely works without some hair-pulling... I've heard many people say the same, so it's not just you and me. As for making it work, I don't have the skills/time, lets hope someone who does is listening. April 2003 was the last time I had a couple of days to spare on making it build. Nobody on #mono or even on this list seems to know how to make it build without fail (at least nobody I've come across). -adam -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joe Mozelesky Sent: Monday, 5 January 2004 1:38 PM To: [EMAIL PROTECTED] Subject: [Mono-list] Mono Windows/Cygwin Repeatable Build Process Importance: High Hello, I was wondering if there were any plans to update mono-build-w32.sh to a working state, or if there is a working build script for Windows/Cygwin floating around out there? I just spent the past 2 days trying to compile Mono on Cygwin. I did a fresh install of Cygwin, and I selected to install _everything_. I have tried building using mono-build-w32.sh, and I have tried building from a tarball, and I have tried checking it out from CVS and building it manually. I keep running into one problem after another. There is no single document describing what is required for a successful build. Following the instructions in the Mono handbook does not work. There are a lot of posts in the mailing list archives about various common problems like libgc not found, autoconf version issues, etc. I have messed with various settings for LDFLAGS, CPPFLAGS, PKG_CONFIG_PATH, LD_LIBRARY_PATH, ACLOCAL_FLAGS, PATH, etc. etc. to no avail. Every time I hack/fix one problem, there is another problem. I would really like to get a setup so I can do a repeatable build from CVS to keep current with various updates/bugfixes. I think this is the intent of the mono-build-w32.sh script. Can all of the above be consolidated into a set of steps that will work and is repeatable? If by some stroke of luck I am able to get this to compile on my laptop, I am going to have to go through this same 2 day process on my desktop trying to get it to build there. Is my experience uncommon? Are others out there able to compile fine on Windows/Cygwin? Is there something I am missing? Isn't there an automated build process that runs every night and verifies the build works successfully and nothing is broken on all target platforms? My setup: Laptop Windows XP Professional SP 1 Cygwin 1.5.5-1 everything installed I have the correct autotools versions after copying the cygwin devel versions into /usr/bin. I corrected the libgc problem by copying gc.dll to /usr/lib. I am now getting errors in mono/metadata about icall.c. I am just frustrated and I am wondering if it is something that I am doing wrong, or if the build script is broken, or if there is some easy way to get a 'reference' environment setup. It seems like others have had success building Mono on Cygwin with relative ease, so I'd like to determine what is different about my clean-install environment. Thanks, Joe ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Mono Windows/Cygwin Repeatable Build Process
Hello, I was wondering if there were any plans to update mono-build-w32.sh to a working state, or if there is a working build script for Windows/Cygwin floating around out there? I just spent the past 2 days trying to compile Mono on Cygwin. I did a fresh install of Cygwin, and I selected to install _everything_. I have tried building using mono-build-w32.sh, and I have tried building from a tarball, and I have tried checking it out from CVS and building it manually. I keep running into one problem after another. There is no single document describing what is required for a successful build. Following the instructions in the Mono handbook does not work. There are a lot of posts in the mailing list archives about various common problems like libgc not found, autoconf version issues, etc. I have messed with various settings for LDFLAGS, CPPFLAGS, PKG_CONFIG_PATH, LD_LIBRARY_PATH, ACLOCAL_FLAGS, PATH, etc. etc. to no avail. Every time I hack/fix one problem, there is another problem. I would really like to get a setup so I can do a repeatable build from CVS to keep current with various updates/bugfixes. I think this is the intent of the mono-build-w32.sh script. Can all of the above be consolidated into a set of steps that will work and is repeatable? If by some stroke of luck I am able to get this to compile on my laptop, I am going to have to go through this same 2 day process on my desktop trying to get it to build there. Is my experience uncommon? Are others out there able to compile fine on Windows/Cygwin? Is there something I am missing? Isn't there an automated build process that runs every night and verifies the build works successfully and nothing is broken on all target platforms? My setup: Laptop Windows XP Professional SP 1 Cygwin 1.5.5-1 everything installed I have the correct autotools versions after copying the cygwin devel versions into /usr/bin. I corrected the libgc problem by copying gc.dll to /usr/lib. I am now getting errors in mono/metadata about icall.c. I am just frustrated and I am wondering if it is something that I am doing wrong, or if the build script is broken, or if there is some easy way to get a 'reference' environment setup. It seems like others have had success building Mono on Cygwin with relative ease, so I'd like to determine what is different about my clean-install environment. Thanks, Joe ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono Windows Binaries contained a virus.
Hello, > Would it be fair to say that this would not happen again? That is to say, > you know how it happened and have addressed the issue? Yes, it was tracked down and solved (the Gtk sharp binaries for example went through this process before being uploaded). Miguel ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Mono Windows Binaries contained a virus.
Hi, Would it be fair to say that this would not happen again? That is to say, you know how it happened and have addressed the issue? Thanks, Richard Miguel de Icaza wrote: > Hello, > >If you downloaded the Windows binaries for Mono 0.20 today (they were > available for about 10 minutes, but we got 30 downloads), please read: > > http://www.go-mono.com/virus.html > > The binaries shipped with a virus. > > We apologize for the inconvenience, > Miguel. > ___ > Mono-list maillist - [EMAIL PROTECTED] > http://lists.ximian.com/mailman/listinfo/mono-list -- NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] Mono Windows Binaries contained a virus.
Here is an updated version which has been virus checked by several people. The updated Windows NT/2000/XP Installer for mono 0.20 is at http://primates.ximian.com/~miguel/tmp/mono-0.20-stable-win32-2.exe Thanks goes to Johannes for helping me set it up, and Lupus for providing the Mono JIT binaries. Enjoy! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Miguel de Icaza Sent: Monday, February 24, 2003 2:54 PM To: [EMAIL PROTECTED] Subject: [Mono-list] Mono Windows Binaries contained a virus. Hello, If you downloaded the Windows binaries for Mono 0.20 today (they were available for about 10 minutes, but we got 30 downloads), please read: http://www.go-mono.com/virus.html The binaries shipped with a virus. We apologize for the inconvenience, Miguel. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Mono Windows Binaries contained a virus.
Hello, If you downloaded the Windows binaries for Mono 0.20 today (they were available for about 10 minutes, but we got 30 downloads), please read: http://www.go-mono.com/virus.html The binaries shipped with a virus. We apologize for the inconvenience, Miguel. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
