[Monodevelop-devel] Error when installing Language Binding from custom repository

Tomas Petricek tomas.petricek at gmail.com
Wed Oct 13 13:13:23 EDT 2010


Hi,
I've been working on an F# Language Binding for MonoDevelop and I'm
trying to create a repository, so that people can install it using the
standard tools. There are still some bugs in the Language Binding, but
when I just copy the DLL to the "BackendBindings" directory in
MonoDevelop folder, then it seems to work okay (it requires F# and F#
PowerPack in order to run). My testing repository is here:
http://www.tomasp.net/monodevelop/

The installation from the repository seems to work fine on Linux/Mono.
The installation reports some errors with the configuration and some
exception occurs when it loads (I guess), but that looks like my bugs
that I can fix (still, it installs and you can create new projects and
everything)

However, I'm having more troubles on Windows/.NET (I'm testing it on a
clean Windows 7 machine with Gtk# and MonoDevelop installed using the
instructions from the web). When I go through the addin installation
procedure, it installs the adding and just before showing the final
dialog window (with success message and warnings), it shows an
"Unhandled Exception." dialog with the following:

System.Reflection.TargetInvocationException: Exception has been thrown
by the target of an invocation.
---> System.AccessViolationException: Attempted to read or write
protected memory.
This is often an indication that other memory is corrupt.

   at Gtk.Dialog.gtk_dialog_run(IntPtr raw)
   at Gtk.Dialog.Run()
   at Mono.Addins.Gui.AddinManagerDialog.OnInstall(Object sender, EventArgs e)
   --- End of inner exception stack trace ---
   at System.RuntimeMethodHandle._InvokeMethodFast(Object target,
Object[] arguments, SignatureStruct& sig, MethodAttributes
methodAttributes, RuntimeTypeHandle typeOwner)
   at System.RuntimeMethodHandle.InvokeMethodFast(Object target,
Object[] arguments, Signature sig, MethodAttributes methodAttributes,
RuntimeTypeHandle typeOwner)
   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj,
BindingFlags invokeAttr, Binder binder, Object[] parameters,
CultureInfo culture, Boolean skipVisibilityChecks)
   at System.Delegate.DynamicInvokeImpl(Object[] args)
   at GLib.Signal.ClosureInvokedCB(Object o, ClosureInvokedArgs args)
   at GLib.SignalClosure.Invoke(ClosureInvokedArgs args)
   at GLib.SignalClosure.MarshalCallback(IntPtr raw_closure, IntPtr
return_val, UInt32 n_param_vals, IntPtr param_values, IntPtr
invocation_hint, IntPtr marshal_data)

I tried attaching to the process from VS debugger and it doesn't seem
to even load my "FSharpBinding.dll" assembly, so I'm wondering if this
could some issue in MonoDevelop itself? I tried creating a trivial
language binding in C# and that worked okay, but I was able to
reproduce the error with the repository above on two different
machines. I can also send you the generated log file from the
installation if you need more information.

I wasn't quite able to figure out what is going on (I think the
exception actually comes from Mono.Addins and I think I've seen errors
like this when accidentally accessing GUI stuff from a background
thread, but I'm not sure if that could be a problem here). Anyway,
this will be probably quite easy to find out for somebody who has
properly setup environment with debug builds of all relevant
libraries.

Thanks for your help!
Tomas Petricek

PS: I think that the Visual Studio projects in monodevelop-2.4 "tag"
(I used that version to make sure my adding works with latest stable
version) incorrectly reference 4.0.0 versions of Mono.Addins etc. (see
for example http://github.com/mono/monodevelop/blob/monodevelop-2.4/main/src/core/MonoDevelop.Ide/MonoDevelop.Ide.csproj).
I tried changed that to 5.0.0 on my machine, but it didn't resolve the
issue I was having.

PS2: I noticed there was a project with the aim to implement F#
support for MonoDevelop at the GSOC this year, but I couldn't find any
outcomes of the project. Is that available somewhere? I tried
contacting the person who worked on that, but with no luck (possibly,
I just got a wrong email). Anyway, I could probably contribute my work
to that project (or the other way round) to avoid duplication of
efforts...


More information about the Monodevelop-devel-list mailing list