After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 639808 - Remove Package elements from Reference elements in csproj files
Remove Package elements from Reference elements in csproj files
Status: RESOLVED FIXED
Product: banshee
Classification: Other
Component: general
git master
Other Windows
: Normal normal
: 1.x
Assigned To: Banshee Maintainers
Banshee Maintainers
Depends on:
Blocks:
 
 
Reported: 2011-01-18 03:18 UTC by Dustin C. Hatch
Modified: 2011-01-26 21:31 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Remove all Package elements from references in csproj files (46.88 KB, patch)
2011-01-18 03:18 UTC, Dustin C. Hatch
committed Details | Review

Description Dustin C. Hatch 2011-01-18 03:18:37 UTC
Created attachment 178578 [details] [review]
Remove all Package elements from references in csproj files

The pkg-config package name for GTK# is different on Windows than on Linux, so MonoDevelop is unable to resolve assembly locations for gtk-sharp, etc. Removing the package name constraint for assembly references lets MonoDevelop find these assemblies and allows the solution to build successfully.

This only affects MonoDevelop because Visual Studio uses the GAC to locate third-party DLLs, whereas MonoDevelop uses pkg-config.
Comment 1 Gabriel Burt 2011-01-18 19:45:11 UTC
Review of attachment 178578 [details] [review]:

I want somebody to test this on Linux using MonoDevelop and make sure it 1) still builds fine and 2) MD on Linux doesn't feel compelled to overwrite it, otherwise we'll be getting patches to do that from lots of people.
Comment 2 Dustin C. Hatch 2011-01-18 19:50:01 UTC
(In reply to comment #1)
> Review of attachment 178578 [details] [review]:
> 
> I want somebody to test this on Linux using MonoDevelop and make sure it 1)
> still builds fine and 2) MD on Linux doesn't feel compelled to overwrite it,
> otherwise we'll be getting patches to do that from lots of people.

I'm sorry, I should have mentioned that I was able to build the solution in MonoDevelop on Linux after making the changes. I did not, however, check to see if it put the package constraints back in. I will look into it when I get a chance. Of course, if someone else can test as well, that would be even better.
Comment 3 Dustin C. Hatch 2011-01-19 00:22:28 UTC
Am I correct in my observation that MonoDevelop on Linux uses automake to build the solution, or have I done something so wrong that it works anyway? After applying the patch, running ``./autogen.sh`` and then running ``make`` in the *build* directory, I was able to get a full build with no errors from within MonoDevelop. Furthermore, ``git status`` still reports that the working copy is clean, so MonoDevelop did not make any modifications to tracked files.
Comment 4 Matt Sturgeon 2011-01-20 23:48:51 UTC
I filed a possibly related Bug 640126.
Comment 5 Bertrand Lorentz 2011-01-22 13:16:30 UTC
Dustin, you're right, as "Makefile integration" is enabled on the projects in the solution, MonoDevelop on Linux will just run "make all".

But Gabriel suspicion was right : after applying this patch, if I go to any project's options dialog and then click "OK", MonoDevelop will modify the .csproj and add the <Package> tags back.
Comment 6 Gabriel Burt 2011-01-24 23:14:56 UTC
Hrm, interesting -- with git master, I opened the .sln in MD 2.4 on Linux, edited Muinshee's references, clicked OK/Close without changing any, but that alone was enough for MD to remove the <Package> references.

What version of MD were you using, Bertrand?  Maybe MD doesn't use <Package> anymore in 2.4
Comment 7 Gabriel Burt 2011-01-26 21:04:47 UTC
Review of attachment 178578 [details] [review]:

OK, I tested with my MonoDevelop (2.4.2) on Linux and it seems fine with this patch.  I'm pretty sure MD on Windows used to be fine with the <Package> entries -- they must have changed how they use them in 2.4.2
Comment 8 Gabriel Burt 2011-01-26 21:31:37 UTC
I committed another patch too fixing a taglib-sharp reference in Banshee.AmazonMp3, and disabling Banshee.Dap.Ipod (since it's obsolete, and if we're going to support iPods etc on Windows, it should be with Banshee.Dap.AppleDevices).  Builds fine for me now.  I have an issue with the gst# engine initializing, but that's a different issue.