MonoDevelop fails to start

I already tried. Output:

$ monodevelop
$

and nothing. Not even the invisible 'starting' window as when I launched
it from the menu. I'll try mono-devel for the time being, just to
compile the bloody thing.

I heard that 4.0.1x is a horrifically buggy release. Any ideas as to why
it worked in Xfce only a week or so ago, and did so consistently
throughout the entire time I used Xfce? I may have to switch back to
Xfce just to use it.

That is really all there is to it. I am running Trisquel 7 Belenos with
belenos, belenos-security, belenos-backports, and belenos-updates
enabled, on an ASUS N43SL, with your very own Trisquel (customised GNOME
fallback) desktop environment. I installed monodevelop with sudo apt-get
install monodevelop, and it went through fine. However, I tried running
monodevelop from both the application menu and from a terminal, with and
without root. When running from the menu, a 'Starting MonoDevelop...'
window (which I could not actually open) appeared in the window
switcher. No monodevelop or related processes were found in the System
Monitor either before, during, or after my run attempts. When running
from terminal, the mysterious hidden window did not appear, and the
command simply gave me a new prompt. monodevelop --no-splash did
nothing, but monodevelop --no-redirect gave this output:

FATAL ERROR [2015-06-22 19:37:47Z]: MonoDevelop failed to start. Some of
the assemblies required to run MonoDevelop (for example gtk-sharp)may
not be properly installed in the GAC.
System.Exception: Toolkit could not be loaded --->
System.IO.FileNotFoundException: Could not load file or assembly
'Mono.Cairo, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=0738eb9f132ed756' or one of its dependencies.
File name: 'Mono.Cairo, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=0738eb9f132ed756'
at System.Reflection.MonoCMethod.InternalInvoke (System.Object obj,
System.Object[] parameters) [0x00000] in :0
at System.Activator.CreateInstance (System.Type type, Boolean
nonPublic) [0x00000] in :0
at System.Activator.CreateInstance (System.Type type) [0x00000] in
:0
at Xwt.Backends.ToolkitEngineBackend.CreateBackend (System.Type
backendType) [0x00000] in :0
at
Xwt.Backends.ToolkitEngineBackend.CreateBackend[TextLayoutBackendHandler] () [0x00000] in :0
at Xwt.Toolkit.Initialize (Boolean isGuest) [0x00000] in :0
at Xwt.Toolkit.LoadBackend (System.String type, Boolean isGuest,
Boolean throwIfFails) [0x00000] in :0
--- End of inner exception stack trace ---
at Xwt.Toolkit.LoadBackend (System.String type, Boolean isGuest,
Boolean throwIfFails) [0x00000] in :0
at Xwt.Toolkit.Load (System.String fullTypeName, Boolean isGuest)
[0x00000] in :0
at Xwt.Application.Initialize (System.String backendType) [0x00000] in
:0
at Xwt.Application.Initialize (ToolkitType type) [0x00000] in
:0
at Xwt.Application.InitializeAsGuest (ToolkitType type) [0x00000] in
:0
at MonoDevelop.Ide.IdeStartup.Run (MonoDevelop.Ide.MonoDevelopOptions
options) [0x00000] in :0
at MonoDevelop.Ide.IdeStartup.Main (System.String[] args) [0x00000] in
:0

From this output, mjmhogg71 suggested installing libmono-cairo2.0-cil. I
did, and that resolved the issue. Monodevelop launches fine now, and
works as advertised. However, upon attempting to compile a piece of C#
code, the status bar thingy at the top of the mono interface complained
of not being able to find a C# compiler. I installed mono-devel (it
probably would have worked with mono-mcs alone) and programs now compile
fine. I fear there may be other problems with missing dependencies.

Currently, neither mono-devel, mono-mcs, or libmono-cairo2.0-cil are
listed as dependencies of the package monodevelop in the package
repository. However, from what I remember of Mono under Debian, all of
these packages were dependencies (though you should probably check the
Debian repo), and it worked fine out of the box.

One strange thing to note: it worked absolutely flawlessly out of the
box no more than two/three weeks ago under Xfce.

To conclude: I think mono-devel and libmono-cairo2.0-cil should be added
to the monodevelop .deb as dependencies. A surefire way of avoiding this
problem in any case.