Help for porting: VC# 2008 express binaries crashing when run by mono

[herenvardo]

I'll try to be short and concise: a few months ago I started developing a project in Microsoft Visual C# 2008 Express Edition, with the idea of making it Mono-compatible. In order to achieve that goal, I have been checking Mono project's progress on this site frequently, and kept running MoMA checks on all my assemblies at least once a week. Now that some pieces of the project start holding together, I've started some testing:
On .NET (3.5 upon Win XP Home SP3), the application runs fine, besides some minor glitches (like "added the wrong icon to that menu" or "forgot to localize the 'Filter' property for this SaveDialog", but no serious errors until now.
Running MoMA on these assemblies only mentions a few ToDo's about the TextBoxBase.Undo() method and the auto-complete stuff on combo-boxes: these are useful features, but no critical after all (and chances are high that Mono 2.0 would be out there before I make a first "stable" release).
Trying to run the applicantion on Mono (1.9.1, upon the same Win system) with a command like:
mono myProgram.exe
apparently does nothing. When I found about the -v switch, I got what I'd guess is an exception's traceback, mentioning calls to OutOfMemoryException's, NullReferenceException's and StackOverflowException's constructors: this cannot be good at all.
I have tried a few helloworld-like programs, to make sure that mono was working properly, and they ran fine.

I have absolutelly no previous experience with Mono, and very limited experience with non-Windows systems (except some DOS tinkering long ago), so I'm completelly lost. I have no idea about how to debug the assembly in mono (ie: try to see what's causing these exceptions), nor even how to compile my project using mono's compiler instead of Microsoft's (maybe the visual compiler is doing something weird). Worst of all (the previous would be actually good otherwise, since it's a chance to learn and a challenge), I've been unable to find any sources about these "basic" topics on the web, such as tutorials, faqs, troubleshooting examples... absolutely nothing after 3 hours of googling.
So, could someone please point me to any resource to, at least, get started in the topic?

Thanks in advance, both on my part and on that of any "non-Windowed" potential user for my project.

Regards,
Herenvardö

[Sebastien Pouliot-2]

On Mon, 2008-06-02 at 11:31 -0700, herenvardo wrote:

> I'll try to be short and concise: a few months ago I started developing a
> project in Microsoft Visual C# 2008 Express Edition, with the idea of making
> it Mono-compatible. In order to achieve that goal, I have been checking Mono
> project's progress on this site frequently, and kept running MoMA checks on
> all my assemblies at least once a week. Now that some pieces of the project
> start holding together, I've started some testing:
> On .NET (3.5 upon Win XP Home SP3), the application runs fine, besides some
> minor glitches (like "added the wrong icon to that menu" or "forgot to
> localize the 'Filter' property for this SaveDialog", but no serious errors
> until now.
> Running MoMA on these assemblies only mentions a few ToDo's about the
> TextBoxBase.Undo() method and the auto-complete stuff on combo-boxes: these
> are useful features, but no critical after all (and chances are high that
> Mono 2.0 would be out there before I make a first "stable" release).
> Trying to run the applicantion on Mono (1.9.1, upon the same Win system)
> with a command like:
> mono myProgram.exe
> apparently does nothing.

Could you be more specific ? e.g. does it just "freeze" there without
showing anything or do you get the command prompt back ? is an empty
window visible ? or a new process ?

> When I found about the -v switch, I got what I'd
> guess is an exception's traceback, mentioning calls to
> OutOfMemoryException's, NullReferenceException's and
> StackOverflowException's constructors: this cannot be good at all.

Actually you're wrong because it's good ;-). The exception are created,
not thrown, at the start of the application because, when the right
situation occurs (like an being out of memory) it's a bad time to create
(allocate) an exception but the perfect time to throw the existing one.

> I have tried a few helloworld-like programs, to make sure that mono was
> working properly, and they ran fine.

And they all should show the same exception creation when starting.

> I have absolutelly no previous experience with Mono, and very limited
> experience with non-Windows systems (except some DOS tinkering long ago), so
> I'm completelly lost. I have no idea about how to debug the assembly in mono
> (ie: try to see what's causing these exceptions), nor even how to compile my
> project using mono's compiler instead of Microsoft's (maybe the visual
> compiler is doing something weird). Worst of all (the previous would be
> actually good otherwise, since it's a chance to learn and a challenge), I've
> been unable to find any sources about these "basic" topics on the web, such
> as tutorials, faqs, troubleshooting examples... absolutely nothing after 3
> hours of googling.
> So, could someone please point me to any resource to, at least, get started
> in the topic?

Start by providing some basic info, like are you using Mono on Windows,
Linux, other OS ? which distro/version (OS) and package/version for
Mono ...

> Thanks in advance, both on my part and on that of any "non-Windowed"
> potential user for my project.

Sebastien

_______________________________________________
Mono-list maillist  -  Mono-list@...
http://lists.ximian.com/mailman/listinfo/mono-list

[herenvardo]

Sebastien Pouliot-2 wrote:

Could you be more specific ? e.g. does it just "freeze" there without
showing anything or do you get the command prompt back ? is an empty
window visible ? or a new process ?

I tried to run the program on mono and get back to the command prompt within 1-2 seconds. The program is a WinForms application and is supposed to display a form when run. The form never appears when running from Mono, nor any kind of error message.
UPDATE: After learning a bit more about mono's command line options, I tried running the program with --debug. I'm attaching the whole trace as a txt file for the case it might be useful, but as a summary: System.Reflection.TargetInvocationException (with System.IndexOutOfRangeException as the inner exception) thrown by System.Windows.Forms.Layout.TableLayoutSettingsTypeConverter.ParseRowStyle( System.Xml.XmlDocument, System.Windows.Forms.TableLayoutSettings). Digging to the base of the trace, I can identify the first calls after the ones within my own code to be the designer-generated code for locacalization. I've tried to localize a variation of the Hello World program to see if it crashes, but it ran properly (actually, .NET erronously took my local language as Spanish, while Mono properly detected it as Catalan). I'll try to investigate further that trace; but being unable to reproduce the problem upon .NET and hence upon the Visual Studio debugger (the environment I'm used to debug under), doesn't help too much.

Sebastien Pouliot-2 wrote:

> I have tried a few helloworld-like programs, to make sure that mono was
> working properly, and they ran fine.

And they all should show the same exception creation when starting.

I didn't use the -v with them originally, because they were working fine; but after reading your reply I checked it and indeed they create the exceptions as well. My mistake was to assume that these messages were a trace: I knew my program was crashing, so there had to be a trace somewhere, and it looked like a trace so I just assumed what seemed to be obvious (despite being actually wrong). Now that I've found the real trace for my program's crash, things make a bit more sense.

Sebastien Pouliot-2 wrote:

Start by providing some basic info, like are you using Mono on Windows,
Linux, other OS ? which distro/version (OS) and package/version for
Mono ...

I'm working upon Windows XP Home Service Pack 3 (the machine is an Acer laptop powered by an AMD Turion 64 2GHz cpu with 1536Mb of RAM, if this info helps). The version of Mono is 1.9.1. for Windows (the package listed as "Mono for Windows, Gtk#, and XSP" in the Mono Downloads page).
The project itself, as of currently, is made of a few assemblies:
towo.dll (doesn't depend on other parts of the project): this is the "core" of the project: it defines a few hundreds types and some thousands of methods to be used by the rest of components.
towoedit.dll (depends only on towo.dll): defines several UserControl derivates providing "editor" UI components for some of the types defined within towo.dll. There are also a couple of multi-purpose forms.
SpellEditorDemo.exe (depends directly on towoedit.dll and indirectly on towo.dll): An extremely simple WinForms application that simply wraps one of the components defined in towoedit.dll to enable testing and trying it.
In addition, there are some satelite resource assemblies for each of the main assemblies, with the translations of texts into Catalan and Spanish (the main assemblies default to English).
All the assemblies have been generated with Microsoft Visual C# 2008 Express Edition; and the projects target the version 3.5 version of the .NET Framework (currently, the only feature used that wouldn't be available on 2.0 are extension methods; with the possibility of using LINQ to XML already in mind).
I want to insist on that MoMA only reported a few TODOs about the Undo and AutoComplete functionalities of some WinForms controls (while these features are indeed useful, they are not critical for the project).
I don't know if there is anything else I should mention about the project and the environment; in that case simply ask.

Thanks again for the time and effort dedicated to helping me in solving this issue. I'll keep trying to figure things out and find answers by myself, and update this thread if I come up with something relevant (even when taking blind shots, one might be lucky enough to eventually hit the target, so it's worth a try).

[Andy Hume]

--debug is generally much more helpful, and *much much much* less verbose, than -v.  Try it and see you get any errors reported on the console then.

IIRC when running a winexe assembly (e.g. a WinForms app) the program will detach from the console and so can't output any errors.  --debug keeps the attachment.  (Or briefly change the build type to "exe" in your VS solution).

Andy

> -----Original Message-----
> From: mono-list-bounces@...
> [mailto:mono-list-bounces@...] On Behalf Of herenvardo
> Sent: 02 June 2008 19:31
> To: mono-list@...
> Subject: [Mono-list] Help for porting: VC# 2008 express
> binaries crashing when run by mono
>
>
> I'll try to be short and concise: a few months ago I started
> developing a project in Microsoft Visual C# 2008 Express
> Edition, with the idea of making it Mono-compatible. In order
> to achieve that goal, I have been checking Mono project's
> progress on this site frequently, and kept running MoMA
> checks on all my assemblies at least once a week. Now that
> some pieces of the project start holding together, I've
> started some testing:
> On .NET (3.5 upon Win XP Home SP3), the application runs
> fine, besides some minor glitches (like "added the wrong icon
> to that menu" or "forgot to localize the 'Filter' property
> for this SaveDialog", but no serious errors until now.
> Running MoMA on these assemblies only mentions a few ToDo's about the
> TextBoxBase.Undo() method and the auto-complete stuff on
> combo-boxes: these are useful features, but no critical after
> all (and chances are high that Mono 2.0 would be out there
> before I make a first "stable" release).
> Trying to run the applicantion on Mono (1.9.1, upon the same
> Win system) with a command like:
> mono myProgram.exe
> apparently does nothing. When I found about the -v switch, I
> got what I'd guess is an exception's traceback, mentioning
> calls to OutOfMemoryException's, NullReferenceException's and
> StackOverflowException's constructors: this cannot be good at all.
> I have tried a few helloworld-like programs, to make sure
> that mono was working properly, and they ran fine.
>
> I have absolutelly no previous experience with Mono, and very
> limited experience with non-Windows systems (except some DOS
> tinkering long ago), so I'm completelly lost. I have no idea
> about how to debug the assembly in mono
> (ie: try to see what's causing these exceptions), nor even
> how to compile my project using mono's compiler instead of
> Microsoft's (maybe the visual compiler is doing something
> weird). Worst of all (the previous would be actually good
> otherwise, since it's a chance to learn and a challenge),
> I've been unable to find any sources about these "basic"
> topics on the web, such as tutorials, faqs, troubleshooting
> examples... absolutely nothing after 3 hours of googling.
> So, could someone please point me to any resource to, at
> least, get started in the topic?
>
> Thanks in advance, both on my part and on that of any "non-Windowed"
> potential user for my project.
>
> Regards,
> Herenvardö
> --
> View this message in context:
> http://www.nabble.com/Help-for-porting%3A-VC--2008-express-bin
> aries-crashing-when-run-by-mono-tp17607386p17607386.html
> Sent from the Mono - General mailing list archive at Nabble.com.
>
> _______________________________________________
> Mono-list maillist  -  Mono-list@...
> http://lists.ximian.com/mailman/listinfo/mono-list
>

_______________________________________________
Mono-list maillist  -  Mono-list@...
http://lists.ximian.com/mailman/listinfo/mono-list

[Jonathan Pobst]

It sounds like a bug in TableLayoutSettingsTypeConverter.ParseRowStyle.
  If you can get the data sent to the parameter xmlDoc that crashes, we
can get a fix for it.

You may also be able to find the information in the .Designer file for
your form.  Whatever is in the InitializeComponents part for your
TableLayoutPanel.

Also, to get the error on Windows, you need to run "mono myApp.exe 2>
error.log" to redirect the error output to a file.

Jonathan


herenvardo wrote:

>
> Sebastien Pouliot-2 wrote:
>> Could you be more specific ? e.g. does it just "freeze" there without
>> showing anything or do you get the command prompt back ? is an empty
>> window visible ? or a new process ?
>>
> I tried to run the program on mono and get back to the command prompt within
> 1-2 seconds. The program is a WinForms application and is supposed to
> display a form when run. The form never appears when running from Mono, nor
> any kind of error message.
> UPDATE: After learning a bit more about mono's command line options, I tried
> running the program with --debug. I'm attaching the whole trace as a txt
> file for the case it might be useful, but as a summary:
> System.Reflection.TargetInvocationException (with
> System.IndexOutOfRangeException as the inner exception) thrown by
> System.Windows.Forms.Layout.TableLayoutSettingsTypeConverter.ParseRowStyle(
> System.Xml.XmlDocument, System.Windows.Forms.TableLayoutSettings). Digging
> to the base of the trace, I can identify the first calls after the ones
> within my own code to be the designer-generated code for locacalization.
> I've tried to localize a variation of the Hello World program to see if it
> crashes, but it ran properly (actually, .NET erronously took my local
> language as Spanish, while Mono properly detected it as Catalan). I'll try
> to investigate further that trace; but being unable to reproduce the problem
> upon .NET and hence upon the Visual Studio debugger (the environment I'm
> used to debug under), doesn't help too much.
>
>
> Sebastien Pouliot-2 wrote:
>>> I have tried a few helloworld-like programs, to make sure that mono was
>>> working properly, and they ran fine.
>> And they all should show the same exception creation when starting.
>>
> I didn't use the -v with them originally, because they were working fine;
> but after reading your reply I checked it and indeed they create the
> exceptions as well. My mistake was to assume that these messages were a
> trace: I knew my program was crashing, so there had to be a trace somewhere,
> and it looked like a trace so I just assumed what seemed to be obvious
> (despite being actually wrong). Now that I've found the real trace for my
> program's crash, things make a bit more sense.
>
>
> Sebastien Pouliot-2 wrote:
>> Start by providing some basic info, like are you using Mono on Windows,
>> Linux, other OS ? which distro/version (OS) and package/version for
>> Mono ...
>>
> I'm working upon Windows XP Home Service Pack 3 (the machine is an Acer
> laptop powered by an AMD Turion 64 2GHz cpu with 1536Mb of RAM, if this info
> helps). The version of Mono is 1.9.1. for Windows (the package listed as
> "Mono for Windows, Gtk#, and XSP" in the Mono Downloads page).
> The project itself, as of currently, is made of a few assemblies:
> towo.dll (doesn't depend on other parts of the project): this is the "core"
> of the project: it defines a few hundreds types and some thousands of
> methods to be used by the rest of components.
> towoedit.dll (depends only on towo.dll): defines several UserControl
> derivates providing "editor" UI components for some of the types defined
> within towo.dll. There are also a couple of multi-purpose forms.
> SpellEditorDemo.exe (depends directly on towoedit.dll and indirectly on
> towo.dll): An extremely simple WinForms application that simply wraps one of
> the components defined in towoedit.dll to enable testing and trying it.
> In addition, there are some satelite resource assemblies for each of the
> main assemblies, with the translations of texts into Catalan and Spanish
> (the main assemblies default to English).
> All the assemblies have been generated with Microsoft Visual C# 2008 Express
> Edition; and the projects target the version 3.5 version of the .NET
> Framework (currently, the only feature used that wouldn't be available on
> 2.0 are extension methods; with the possibility of using LINQ to XML already
> in mind).
> I want to insist on that MoMA only reported a few TODOs about the Undo and
> AutoComplete functionalities of some WinForms controls (while these features
> are indeed useful, they are not critical for the project).
> I don't know if there is anything else I should mention about the project
> and the environment; in that case simply ask.
>
> Thanks again for the time and effort dedicated to helping me in solving this
> issue. I'll keep trying to figure things out and find answers by myself, and
> update this thread if I come up with something relevant (even when taking
> blind shots, one might be lucky enough to eventually hit the target, so it's
> worth a try).

_______________________________________________
Mono-list maillist  -  Mono-list@...
http://lists.ximian.com/mailman/listinfo/mono-list

[herenvardo]

Jonathan Pobst wrote:

It sounds like a bug in TableLayoutSettingsTypeConverter.ParseRowStyle.
  If you can get the data sent to the parameter xmlDoc that crashes, we
can get a fix for it.

That's easier said than done: the Visual Studio's debugger obviously won't allow me to step into the .NET's own code; and the Mono debugger... after more than three hours to find it, get it, and trying to getting it working with no success, I've finally given up.
I've also tried to put all the System.Windows.Forms files from Mono's source inside the project, and remove the reference to .NET's own System.Windows.Forms namespace, hoping to be able to step into that code, but the Studio's compiler didn't swallow it.
If there is anything else I can try to retrieve this value; or if the Mono debugger can be run on windows without being a makefile-expert (one of the reasons I work on Visual is that I really love being able to compile everything with just hitting F6 ^^), I'm open to suggestions.

Jonathan Pobst wrote:

You may also be able to find the information in the .Designer file for
your form.  Whatever is in the InitializeComponents part for your
TableLayoutPanel.

I'm quite familiar with the designer files (I could perfectly build them up from scratch, only that having the designer that can do it for me, why would I bother?), but it didn't reveal anything useful. The code in there simply does what you'd expect it to: initializes the components (creates each control, sets its properties, and then initializes and adds each children control). The nesting of containers might be a bit messy for that designer, but there is no hint about where the error comes from.

Jonathan Pobst wrote:

Also, to get the error on Windows, you need to run "mono myApp.exe 2>
error.log" to redirect the error output to a file.

Well, I actually used "mono myApp.exe>error.log 2<&1", since I didn't know if some output would be going through stdout (better safe than sorry). This reminds me that I forgot to attach the actual log file in my previous post, so here it goes: monocrash.log

[Andreas Färber]

Am 06.06.2008 um 02:22 schrieb herenvardo:

> Jonathan Pobst wrote:
>>
>> It sounds like a bug in  
>> TableLayoutSettingsTypeConverter.ParseRowStyle.
>>  If you can get the data sent to the parameter xmlDoc that crashes,  
>> we
>> can get a fix for it.
>>
> That's easier said than done: the Visual Studio's debugger obviously  
> won't
> allow me to step into the .NET's own code; and the Mono debugger...  
> after
> more than three hours to find it, get it, and trying to getting it  
> working
> with no success, I've finally given up.
> I've also tried to put all the System.Windows.Forms files from  
> Mono's source
> inside the project, and remove the reference to .NET's own
> System.Windows.Forms namespace, hoping to be able to step into that  
> code,
> but the Studio's compiler didn't swallow it.
> If there is anything else I can try to retrieve this value;

You can always resort to Console.WriteLine. :-)

Andreas

> or if the Mono
> debugger can be run on windows without being a makefile-expert (one  
> of the
> reasons I work on Visual is that I really love being able to compile
> everything with just hitting F6 ^^), I'm open to suggestions.
_______________________________________________
Mono-list maillist  -  Mono-list@...
http://lists.ximian.com/mailman/listinfo/mono-list

[Andy Hume]

I think I've found the problem -- it depends on a MSFT bug that creates bad content.   To check that it's the same fault, I'd need to see the input XML.  Rather than dealing with debuggers (eek) can you just search all the files in the project for XML starting with element TableLayoutSettings.

I don't really understand where MSFT uses this content, if not in the .Designer file, then probably in a .resx file.  Did the project start out in VS2008, or maybe in VS2003?  I can't get VS2005 to create such content.

I have unit tests nearly ready to show this and another wee bug in TableLayoutSettingsTypeConverter.

Andy

[Andrus Moor-2]

> the Visual Studio's debugger obviously won't
> allow me to step into the .NET's own code;

Even free C# Express 2008 allows to step into MS System.Windows.Forms.dll
source code.
Maybe we can use instructions from

http://www.codeproject.com/KB/dotnet/netmassdownloader.aspx

to debug MONO SWF source also.

Andrus.

_______________________________________________
Mono-list maillist  -  Mono-list@...
http://lists.ximian.com/mailman/listinfo/mono-list

[herenvardo]

Andy Hume wrote:

I think I've found the problem -- it depends on a MSFT bug that creates bad content.   To check that it's the same fault, I'd need to see the input XML.  Rather than dealing with debuggers (eek) can you just search all the files in the project for XML starting with element TableLayoutSettings.

Search found 0 matches :(. I tried for both "<TableLayout" and ":TableLayout" (just for case the xml uses some namespaces), ignoring case, looking through all the files within my solution's folder (including subfolders, hidden & system stuff, and so on). Removing the "<" or the ":" at the beginning (just looking for raw text, regardless of it's actually XML) yields some results (both .resx XML files and .cs code files); but searching for "TableLayoutSettings" doesn't find anything.
My best guess is that the exact XML input passed to the crashing function is generated "on-the-fly" from the properties and all other details about the panel, during execution. (Otherwise, the "TableLayoutSettings" string should appear, at least, somewhere within the .dll and/or .exe files).

Andy Hume wrote:

I don't really understand where MSFT uses this content, if not in the .Designer file, then probably in a .resx file.  Did the project start out in VS2008, or maybe in VS2003?  I can't get VS2005 to create such content.

The whole solution initially started as a VC# 2005 Express solution; and was upgraded to 2008 as soon as I got the final version of the new IDE. A few weeks ago, I switched it from targeting the .NET 2.0 to .NET 3.5, with the aim of defining some extension methods. For what it matters, most of the code (including the parts causing the problem, which are quite recent), has been developed under VC# 2008 Express.

If you want to check them, I'm attaching the two .cs files (my code and the .Designer.cs), and the resx files for the UserControl that is raising the issue: spell.zip. (The actual application is a mere wrapping just to test that control).

Andrus Moor-2 wrote:

Even free C# Express 2008 allows to step into MS System.Windows.Forms.dll
source code.
Maybe we can use instructions from

http://www.codeproject.com/KB/dotnet/netmassdownloader.aspx

to debug MONO SWF source also.

Rather that saying that the Express edition "allows" stepping into that code, it'd be more accurate that this article provides a workaround to enable that.
Anyway, I've tried the downloader and got lots of 404 errors while trying to fetch the sources. I haven't been able to step into the calls that pass the relevant xml data, but will keep trying to get it working.

Andreas Färber wrote:

You can always resort to Console.WriteLine. :-)

Of course... If you know it, could you please me how can I make .NET's own code to call WriteLine when I want to and with the arguments I'd want? If you take a look at the traceback I attached on my previous post, you'd find that it's not directly my code, but a function from the Framework, which throws the exception. The key of the issue seems to be the XmlDocument passed to that function, and it's not passed from my code, but from other functions within the framework. Of the 34 calls on that trace, only the 7 at the bottom are actually part of my own code; the problem is manifesting on the top call, and its source is somewhere between those 27 calls I have no control over.

Actually, I think I've just come up with some answer to my own question "how can I make .NET's own code to call WriteLine when I want to and with the arguments I'd want?"... which involves a lot of reflection and even more headaches. I'll try to use reflection to "dig" into these calls and retrieve that fatal XmlDocument argument; I will update this thread if I'm able to get it.

[Jonathan Pobst]

I've attached the relevant data from your .resx file.  A quick guess
says it's probably using a culture that uses comma separators instead of
decimal points for numbers, and our code is not international-proof.

This should be pretty easy to fix.  Either Andy or I will probably get
to it in the next couple of days.

Thanks for sending your files!
Jonathan


herenvardo wrote:

>
> Andy Hume wrote:
>> I think I've found the problem -- it depends on a MSFT bug that creates
>> bad content.   To check that it's the same fault, I'd need to see the
>> input XML.  Rather than dealing with debuggers (eek) can you just search
>> all the files in the project for XML starting with element
>> TableLayoutSettings.
>>
> Search found 0 matches :(. I tried for both "<TableLayout" and
> ":TableLayout" (just for case the xml uses some namespaces), ignoring case,
> looking through all the files within my solution's folder (including
> subfolders, hidden & system stuff, and so on). Removing the "<" or the ":"
> at the beginning (just looking for raw text, regardless of it's actually
> XML) yields some results (both .resx XML files and .cs code files); but
> searching for "TableLayoutSettings" doesn't find anything.
> My best guess is that the exact XML input passed to the crashing function is
> generated "on-the-fly" from the properties and all other details about the
> panel, during execution. (Otherwise, the "TableLayoutSettings" string should
> appear, at least, somewhere within the .dll and/or .exe files).
>
>
> Andy Hume wrote:
>> I don't really understand where MSFT uses this content, if not in the
>> .Designer file, then probably in a .resx file.  Did the project start out
>> in VS2008, or maybe in VS2003?  I can't get VS2005 to create such content.
>>
> The whole solution initially started as a VC# 2005 Express solution; and was
> upgraded to 2008 as soon as I got the final version of the new IDE. A few
> weeks ago, I switched it from targeting the .NET 2.0 to .NET 3.5, with the
> aim of defining some extension methods. For what it matters, most of the
> code (including the parts causing the problem, which are quite recent), has
> been developed under VC# 2008 Express.
>
> If you want to check them, I'm attaching the two .cs files (my code and the
> .Designer.cs), and the resx files for the UserControl that is raising the
> issue:  http://www.nabble.com/file/p17694700/spell.zip spell.zip . (The
> actual application is a mere wrapping just to test that control).
>
>
> Andrus Moor-2 wrote:
>> Even free C# Express 2008 allows to step into MS System.Windows.Forms.dll
>> source code.
>> Maybe we can use instructions from
>>
>> http://www.codeproject.com/KB/dotnet/netmassdownloader.aspx
>>
>> to debug MONO SWF source also.
>>
> Rather that saying that the Express edition "allows" stepping into that
> code, it'd be more accurate that this article provides a workaround to
> enable that.
> Anyway, I've tried the downloader and got lots of 404 errors while trying to
> fetch the sources. I haven't been able to step into the calls that pass the
> relevant xml data, but will keep trying to get it working.
>
>
> Andreas Färber wrote:
>> You can always resort to Console.WriteLine. :-)
>>
> Of course... If you know it, could you please me how can I make .NET's own
> code to call WriteLine when I want to and with the arguments I'd want? If
> you take a look at the traceback I attached on my previous post, you'd find
> that it's not directly my code, but a function from the Framework, which
> throws the exception. The key of the issue seems to be the XmlDocument
> passed to that function, and it's not passed from my code, but from other
> functions within the framework. Of the 34 calls on that trace, only the 7 at
> the bottom are actually part of my own code; the problem is manifesting on
> the top call, and its source is somewhere between those 27 calls I have no
> control over.
>
> Actually, I think I've just come up with some answer to my own question "how
> can I make .NET's own code to call WriteLine when I want to and with the
> arguments I'd want?"... which involves a lot of reflection and even more
> headaches. I'll try to use reflection to "dig" into these calls and retrieve
> that fatal XmlDocument argument; I will update this thread if I'm able to
> get it.

  <data name="tlpGeneral.LayoutSettings" type="System.Windows.Forms.TableLayoutSettings, System.Windows.Forms">
    <value><?xml version="1.0" encoding="utf-16"?><TableLayoutSettings><Controls><Control Name="pDetails" Row="2" RowSpan="1" Column="0" ColumnSpan="1" /><Control Name="pSummary" Row="1" RowSpan="1" Column="0" ColumnSpan="1" /><Control Name="pGeneral" Row="0" RowSpan="1" Column="0" ColumnSpan="1" /></Controls><Columns Styles="AutoSize,0" /><Rows Styles="Absolute,105,Percent,50,Percent,50" /></TableLayoutSettings></value>
  </data>

  <data name="tlpCode.LayoutSettings" type="System.Windows.Forms.TableLayoutSettings, System.Windows.Forms">
    <value><?xml version="1.0" encoding="utf-16"?><TableLayoutSettings><Controls><Control Name="pRun" Row="4" RowSpan="1" Column="0" ColumnSpan="1" /><Control Name="pCost" Row="3" RowSpan="1" Column="0" ColumnSpan="1" /><Control Name="pRefs" Row="1" RowSpan="1" Column="0" ColumnSpan="1" /><Control Name="pLanguage" Row="0" RowSpan="1" Column="0" ColumnSpan="1" /><Control Name="pMeta" Row="2" RowSpan="1" Column="0" ColumnSpan="1" /></Controls><Columns Styles="Percent,100" /><Rows Styles="Absolute,25,Absolute,25,Percent,33,33333,Percent,33,33333,Percent,33,33333" /></TableLayoutSettings></value>
  </data>

  <data name="tlpVars.LayoutSettings" type="System.Windows.Forms.TableLayoutSettings, System.Windows.Forms">
    <value><?xml version="1.0" encoding="utf-16"?><TableLayoutSettings><Controls><Control Name="pVarType" Row="1" RowSpan="1" Column="1" ColumnSpan="1" /><Control Name="lstVars" Row="0" RowSpan="1" Column="0" ColumnSpan="3" /><Control Name="pVarsButtons" Row="1" RowSpan="1" Column="2" ColumnSpan="1" /><Control Name="pVarName" Row="1" RowSpan="1" Column="0" ColumnSpan="1" /></Controls><Columns Styles="Percent,50,Percent,50,Absolute,101" /><Rows Styles="Percent,100,Absolute,28" /></TableLayoutSettings></value>
  </data>
_______________________________________________
Mono-list maillist  -  Mono-list@...
http://lists.ximian.com/mailman/listinfo/mono-list

[Andreas Färber]

Am 06.06.2008 um 17:17 schrieb herenvardo:

> Andreas Färber wrote:
>>
>> You can always resort to Console.WriteLine. :-)
>>
> Of course... If you know it, could you please me how can I  
> make .NET's own
> code to call WriteLine when I want to and with the arguments I'd  
> want? If
> you take a look at the traceback I attached on my previous post,  
> you'd find
> that it's not directly my code, but a function from the Framework,  
> which
> throws the exception. The key of the issue seems to be the XmlDocument
> passed to that function, and it's not passed from my code, but from  
> other
> functions within the framework. Of the 34 calls on that trace, only  
> the 7 at
> the bottom are actually part of my own code; the problem is  
> manifesting on
> the top call, and its source is somewhere between those 27 calls I  
> have no
> control over.
>
> Actually, I think I've just come up with some answer to my own  
> question "how
> can I make .NET's own code to call WriteLine when I want to and with  
> the
> arguments I'd want?"... which involves a lot of reflection and even  
> more
> headaches. I'll try to use reflection to "dig" into these calls and  
> retrieve
> that fatal XmlDocument argument; I will update this thread if I'm  
> able to
> get it.

You said Mono is giving you the error, not .NET.

So you'd need to insert the Console.WriteLine(xmldoc.OuterXml) or  
similar in *Mono's* source code, which is Open Source (mcs/class/
Managed.Windows.Forms/namespace/class.cs). Afterwards, `make  
PROFILE=net_2_0` and `make install PROFILE=net_2_0` should compile and  
install it to Mono's GAC.

You might also find this helpful:
http://www.mono-project.com/Debugging_Tips_for_Windows

Andreas

_______________________________________________
Mono-list maillist  -  Mono-list@...
http://lists.ximian.com/mailman/listinfo/mono-list

[herenvardo]

Jonathan Pobst wrote:

I've attached the relevant data from your .resx file.  A quick guess
says it's probably using a culture that uses comma separators instead of
decimal points for numbers, and our code is not international-proof.

This should be pretty easy to fix.  Either Andy or I will probably get
to it in the next couple of days.

I can confirm your guess: I did a bit of testing and replaced all these 33,3333 values in the resx file by 33: integer, so no issue about decimal separators. There might be a bit of precission loss in the distribution of the table rows (anyway, that's less than 1% in the worst case). After that, I recompiled from VS and tried it with Mono: everything is working fine now.
Also, I'm working on a machine with a Spanish version of Windows and the regional configuration set to Catalan: both cultures use the comma as the decimal separator.
Seeing the parts of the .resx file you highlighted, the issue seems quite obvious: comma-separated values where some of the values contain commas themselves: how could that **not** cause problems?
I think the bug should be fixed, because it's a bug after all; but right now my program is able to just avoid it. If there is anything I can do to help fixing it, just let me know.

Jonathan Pobst wrote:

Thanks for sending your files!

Thanks to all of you for all the help! Once finished, the project is going to be published under GPL, so sharing some sources was not a problem :P

[Andy Hume]

I've created bug 398274 (https://bugzilla.novell.com/show_bug.cgi?id=398274) and attached a pile of unit-tests.  They identify this and another wee bug.  I assigned it to Jonathan for fix. :-)

Just in passing, the XML format for the settings is only used when the Form has Localizable=true, that's why I wasn't seeing it initially in my VS2005 test project.  And the comma format occur when VS is running on a machine which such a current culture; and the comma/decimal point only occurs with non-integer percentages.  So a workaround is to negate any of those -- as you did, making the percentages whole numbers is likely easiest.

Andy

herenvardo wrote:

Jonathan Pobst wrote:

I've attached the relevant data from your .resx file.  A quick guess
says it's probably using a culture that uses comma separators instead of
decimal points for numbers, and our code is not international-proof.

This should be pretty easy to fix.  Either Andy or I will probably get
to it in the next couple of days.

I can confirm your guess: I did a bit of testing and replaced all these 33,3333 values in the resx file by 33: integer, so no issue about decimal separators. There might be a bit of precission loss in the distribution of the table rows (anyway, that's less than 1% in the worst case). After that, I recompiled from VS and tried it with Mono: everything is working fine now.
Also, I'm working on a machine with a Spanish version of Windows and the regional configuration set to Catalan: both cultures use the comma as the decimal separator.
Seeing the parts of the .resx file you highlighted, the issue seems quite obvious: comma-separated values where some of the values contain commas themselves: how could that **not** cause problems?
I think the bug should be fixed, because it's a bug after all; but right now my program is able to just avoid it. If there is anything I can do to help fixing it, just let me know.

Jonathan Pobst wrote:

Thanks for sending your files!

Thanks to all of you for all the help! Once finished, the project is going to be published under GPL, so sharing some sources was not a problem :P

[Andy Hume]

Its (relatively) easily to debug into Mono SWF code, its described at http://www.mono-project.com/Guide:_Debugging_With_MWF.  In short when compiling the app, replace the SWF reference to the MWF assembly -- which needs to be *non*-StrongNamed or the real SWF assembly will be loaded at runtime.


Its a bit of a shame that the original app needs to be recompiled for this to work.  It'd be great if Cecil could be used to remap the SWF reference at runtime, in a wee app like:

   [STAThread]
   static void Main()
   {
      // Choose the target WinForms app
      OpenFileDialog dlg = new OpenFileDialog();
      DialogResult rslt = dlg.ShowDialog();
      if (rslt != DialogResult.OK)
         return;
      String path = dlg.FileName;
      Assembly appOrig = Assembly.LoadFile(path);
      // Cecil magic!
      Assembly app = RemapSwfToMwf(appOrig);
      //
      MethodInfo mi = app.EntryPoint;
      Object[] appArguments = CreateCommandLineArgs(mi);
      // Run!
      mi.Invoke(null, appArguments);
   }

It would be great if someone would like to look at this. :-)


Also, any mention in Mono lists of MSFT code access should probably have a wee note saying: don't use it if you might every want to contribute to Mono.

Andy

Andrus Moor-2 wrote:

> the Visual Studio's debugger obviously won't
> allow me to step into the .NET's own code;

Even free C# Express 2008 allows to step into MS System.Windows.Forms.dll
source code.
Maybe we can use instructions from

http://www.codeproject.com/KB/dotnet/netmassdownloader.aspx

to debug MONO SWF source also.

Andrus.

_______________________________________________
Mono-list maillist  -  [e-mail]
http://lists.ximian.com/mailman/listinfo/mono-list