Bug 3180 - Mono.Cairo referencing problem when building addin
Summary: Mono.Cairo referencing problem when building addin
Status: RESOLVED FIXED
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Deployment ()
Version: unspecified
Hardware: PC Windows
: High normal
Target Milestone: ---
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2012-02-01 12:12 UTC by alex
Modified: 2013-12-04 16:58 UTC (History)
2 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED FIXED

Description alex 2012-02-01 12:12:56 UTC
Hi again,

On my windows system, it seems that I don't have the Mono.Cairo v4.0 library, only v2.0
As I wanted the online addin builder to compile the code with a v2.0 library, it gave me the following error:

Gui/HighlightUsagesExtension.cs(128,30): error CS0535: `MonoDevelop.D.Gui.HighlightUsagesExtension.UsageMarker' does not implement interface member `Mono.TextEditor.IBackgroundMarker.DrawBackground(Mono.TextEditor.TextEditor, Cairo.Context, Mono.TextEditor.TextViewMargin.LayoutWrapper, int, int, int, int, double, double, double, ref bool)'
(This source is available at
https://github.com/aBothe/Mono-D/blob/master/MonoDevelop.DBinding/Gui/HighlightUsagesExtension.cs line 142)

,whereas it is compiling everything with the v4.0 library flawlessly -- So I can guarantee that the DrawBackground method is fully implemented (since I can compile it on my local machine, too).

I tested it on a second Windows configuration - it isn't working either.

So you may know why it isn't accepting the v2.0 version? Or why there is no v4.0 available for Windows?
How is MonoDevelop compiled concerning externals?
Nevertheless I'd like to stay on System v4.0 etc, just to switch over to Mono.Cairo v2.0 -- Or shall I do two different builds, one for Windows, the others for Linux/Mac?

http://addins.monodevelop.com/Project/Index/27
https://github.com/aBothe/Mono-D
Comment 1 Mikayla Hutchinson [MSFT] 2012-02-01 12:55:31 UTC
Mono.Cairo and Mono.Posix both have this problem. For some reason they were included in the Mono framework directories, and are transparently upgraded when targeting or running on a newer runtime. This is despite the fact they are identical (except for the corlib reference) - so there is no reason I know to have the 4.0 version.

Since .NET doesn't perform these automatic upgrades, and GTK# is built against .NET 2.0 and therefore references the 2.0 dlls, we have to use 2.0 on .NET. Unfortunately you couldn't build against 2.0 on Mono when targeting the 4.0 framework because of the way Mono upgrades these assembly references.

The upshot is that an addin built on .NET should work on Mono, but an addin built on Mono might not work on .NET.

I don't know an easy fix, unfortunately.
Comment 2 alex 2012-02-01 13:47:53 UTC
Since I was able to distribute the addin before moving to addins.md.com, I guess it's 'simply' needed to enforce Mono.Cairo v2.0 - even linux/mac users don't have problems with that 'older' version.
.. but then, like I already said, this one error shows up .. I guess it's the Cairo.Context object -- can't I configure the project in any way how it won't require a specific Mono.Cairo, even after compilation? (So it won't care neither about v2.0 nor v4.0?) -- Or how could I have two configurations? - nevertheless, in no way it is able to run on windows. I can't compile it with 4.0, I can't compile it with 2.0 :-/
Comment 3 Mikayla Hutchinson [MSFT] 2012-02-01 14:49:12 UTC
Looking more closely at the error, maybe the addin builder is building with a different/incompatible version of MD?
Comment 4 alex 2012-02-01 15:06:57 UTC
Ok there is a temporary workaround for this - I disabled the Usages highlighting so it won't use Mono.Cairo anymore. Anyway I guess if there are other apps using that library it's strongly recommended to handle this issue - perhaps let the gtk# crew bring a next version or something, dunno, since you said there aren't any feature changes in Mono.Cairo or Posix .. But thanks in advance, anyway! :)
Comment 5 alex 2012-02-07 10:14:50 UTC
The build log says /reference:/home/builder/cydin-files/AppReleases/2.7/Mono.TextEditor.dll when it was about to call dmcs. 

The main problem is that given Mono.TextEditor.dll, because it contains the declaration of IBackgroundMarker.DrawBackground - I tried to use my custom version (I just took it from my MD fork) of this dll, and it didn't work, because the builder overwrote the project's reference(s).

If it took my version, it'd expect Mono.Cairo v2.0 (I simply forced it to reference the 2.0 version) - which led to a succesful compilation.

So I recommend that if a custom version of a MonoDevelop library is used, this kind of overwriting shouldn't happen anymore.

This should solve the problem (At least I really guess so!) :)
Comment 6 alex 2012-02-07 20:07:14 UTC
No chance - I noticed that even showing the D Settings under a normal MD windows  installation caused an exception due to a missing Mono.Posix 4.0 -- I really can't understand why there is absolutely no cairo/posix 4.0 on Windows - funny to see that most users actually are/were using Mono-D on windows;
I removed the Win32 from the package publishing service and re-opened my custom repository.

Syndrome eliminated, the main problem still remains...
Comment 7 alex 2013-12-04 16:58:55 UTC
Okay, it seems that the problem has finally been solved..probably since the last gtk# update for windows! :)