Mono crashes while executing mono + Gtk# applications

Bug #882501 reported by baltasarq on 2011-10-27
This bug affects 4 people
Affects Status Importance Assigned to Milestone
mono (Ubuntu)

Bug Description

Platform: Intel x32 + Ubuntu Oneiric 11.10
Package version: 2.10.5-1

This error is still present in Ubuntu Oneiric for mono applications created with monodevelop and using Gtk#, but not, for some reason, applications bundled with the operating system.

The same happened to me in Windows, and the problem disappeared upgrading to the current version of Mono (2.10.6). I guess this is going to be the same thing.

Unfortunately, recompiling applications is not an option, as Monodevelop 2.6 is unable to find the Gtk# in the system (?). Again, the same happened to me in Windows, and upgrading to the current version of MonodeDevelop (2.8) solved the problem.

Would it be possible to upgrade these packages to their current versions, so this bugs disappear?
If not, how can I solve this in my system, so I'm able to use mono again?

baltasarq (baltasarq) wrote :

The crash information is as follows, being tacto.exe a moo application created with Monodevelop:

$ mono tacto.exe
Gtk-Message: Failed to load module "canberra-gtk-module"
Missing method System.Type::op_Inequality(Type,Type) in assembly /usr/lib/mono/2.0/mscorlib.dll, referenced in assembly /usr/lib/mono/gac/gtk-sharp/

Unhandled Exception: System.MissingMethodException: Method not found: 'System.Type.op_Inequality'.
  at Tacto.Gui.MainWindow..ctor () [0x00000] in <filename unknown>:0
  at Tacto.MainClass.Main (System.String[] args) [0x00000] in <filename unknown>:0
[ERROR] FATAL UNHANDLED EXCEPTION: System.MissingMethodException: Method not found: 'System.Type.op_Inequality'.
  at Tacto.Gui.MainWindow..ctor () [0x00000] in <filename unknown>:0
  at Tacto.MainClass.Main (System.String[] args) [0x00000] in <filename unknown>:0

Pekka Karjalainen (pekkakarj) wrote :

Some statements I found in a series of web searches suggest that Oneiric uses the CLI 4.0 runtime, and thus required using the appropriate compiler for C# code and appropriate settings in Monodevelop. According to them, you should use the dmcs compiler instead of gmcs. There is also a specific setting in Monodevelop to compile for the 4.0 CLI runtime.

I managed to verify that, on Oneiric, a simple hello world window application using GTK# compiles with dmcs on the command line and run without the error shown above. If I use gmcs to compile it, it throws the same exception and crashes the same way as above.

I learned that dmcs is the compiler to use for CLI 4.0 from here:

The 2nd message here recommends setting the "build -> runtime version" option in Monodevelop to Mono / 4.0. :

I haven't tested the Monodevelop setting yet, because I haven't yet installed it on my computer. Dmcs is in the mono-dmcs package.

baltasarq (baltasarq) wrote :

Thanks for your interest. I had reached to the very same web pages by myself (it seems they are the only ones talking about this problem). I don't think this means that the bug is solved, though. The mono CLI should be able to run apps compiled for the .NET 3.5 profile, or mono CLI 2.0, not only mono CLI 4.0.

If you do a apt-cache search mono:

$ apt-cache search libmono
libmono-system2.0-cil - Mono System libraries (for CLI 2.0)
libmono-system4.0-cil - Mono System libraries (for CLI 4.0)
libmono2.0-cil - Mono libraries (for CLI 2.0)

i.e, the mono libraries for 2.0 are there. More over, mono has not the "right" to choose whether to run an application or not based on the profile (.NET 3.5/.NET 4.0) it was compiled. In order to be compliant, mono should still run apps for .NET 1.0 (if such thing does still exist), and not crash with a strange error saying that some method that obviously should be there is not found.

Probably the bug has to do with mono being unable to change to the CLI 2.0 profile when executing a CLI 2.0 app. Surely the problem is that it is unable to choose the right CLI depending to which one the app was compiled against.

Also, the problem with MonoDevelop still persists... it is actually useless, for Gtk# apps, as it is. Well, actually I was able to compile and run without problems a project which is not using Gtk# (it uses the SDL lib), ans which was targeting the .NET 3.5 (CLI 2.0) profile (?).

I honestly think that all of this would be solved at once just by upgrading Monodevelop and Mono versions. I know because, as I said, I had the same misterious problems in Windows, and upgrading solved them.

Stephen A. Goss (postfuturist) wrote :

This also affects local builds of Banshee:

$ make run
[Info 12:48:18.732] Running Banshee 2.0.1: [git-checkout (linux-gnu, x86_64) @ 2011-11-03 12:36:24 PDT]
[1 Debug 12:48:18.756] Initializing GTK
Missing method System.Reflection.Assembly::op_Equality(Assembly,Assembly) in assembly /usr/lib/mono/2.0/mscorlib.dll, referenced in assembly /usr/lib/mono/gac/Mono.Addins/
Exception has been thrown by the target of an invocation.
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.MissingMethodException: Method not found: 'System.Reflection.Assembly.op_Equality'.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in mono (Ubuntu):
status: New → Confirmed
Stephen A. Goss (postfuturist) wrote :

The solution to building Banshee that runs is to build with ` MCS=/usr/bin/mono-csc`.

baltasarq (baltasarq) wrote :

In the Xamarin mono list, Ian Norton came up with a patch... if you launch the application with --runtime=v4.0, then your app will launch, no matter whether it has been compiled for .NET 3.5 or 4.0. For example:

$ mono --runtime=v4.0 app.exe

Instead of:

$ mono app.exe

This is not a fix, but certainly relaxes the importance of the problem. The fix will probably be to upgrade mono. The need of running all apps as if they were .NET 4.0, denotes that something is broken in this version of mono.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers