Bug 8483 - mono bundles outdated SharpZipLib 0.84
Summary: mono bundles outdated SharpZipLib 0.84
Alias: None
Product: Class Libraries
Classification: Mono
Component: SharpZipLib ()
Version: 2.10.x
Hardware: PC Linux
: --- normal
Target Milestone: Untriaged
Assignee: Bugzilla
URL: https://github.com/mono/mono/pull/529
Depends on:
Reported: 2012-11-18 09:19 UTC by Matthias Mailänder
Modified: 2015-05-02 02:47 UTC (History)
3 users (show)

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 GitHub or Developer Community 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:

Description Matthias Mailänder 2012-11-18 09:19:54 UTC
I have a program that requires SharpZipLib 0.86 as there has been an namespace break somewhere between version 0.84 and 0.86. I tried to create an RPM that installs the new version with gacutil -i bin/ICSharpCode.SharpZipLib.dll -package 2.0 However this will create an rpm-conflict with mono-core on openSUSE which deliverers SharpZipLib 0.84. If I use gacutil -i bin/ICSharpCode.SharpZipLib.dll -package sharpziplib I will get "error CS0006: Metadata file `ICSharpCode.SharpZipLib.dll' could not be found" when trying to make my project that requires SharpZipLib 0.86.

Currently Mono ports the DLL hell to Unix for me. :) It might be the easiest solution if you would just upgrade SharpZipLib to the latest 0.86 from http://www.icsharpcode.net/opensource/sharpziplib/ in your mono distribution, which might also fix some bugs. If there is a way to solve this with gacutil alone, please tell me.
Comment 1 Matthias Mailänder 2013-01-19 12:43:57 UTC
Should be fixed in https://github.com/mono/mono/pull/529 Cross-posted at http://community.sharpdevelop.net/forums/p/16491/45052.aspx
Comment 2 Miguel de Icaza [MSFT] 2013-02-09 17:20:13 UTC
If the API has broken, we can not just merge this patch, since it would break applications for everyone.

The options are:
(a) Identity bug fixes and backport to our version
(b) Sort out a way for you to use the upstream version.

Your issue above seems like a path issue, more than anything else.
Comment 3 Andres G. Aragoneses 2013-02-09 17:33:54 UTC
Hey Miguel, am also interested in this bug:

(In reply to comment #2)
> ...
> (b) Sort out a way for you to use the upstream version.b

Would you accept a pull request that added a flag, for example, to the configure phase (https://github.com/mono/mono/blob/master/configure.in) which would prevent the installation of these kind of libraries? I'm also thinking of NUnit which is kind of old too.

This way distros could use this flag when generating mono packages in case they want to include separate and independent SharpZipLib and NUnit packages.

How about "--disable-libs-install"?
Comment 4 Miguel de Icaza [MSFT] 2013-02-09 21:52:09 UTC
not really, this is a breaking change.

.NET has a way of coping with that, with strong names with version numbers, and we augment that with pkg-config.

So for those cases, the upstream libraries need to ship the proper version/scripts/pkg-config files so that end-users can use those.   

But those should be side-by-side installable with the ones provided by us.
Comment 5 Andres G. Aragoneses 2013-02-22 16:43:57 UTC
Miguel, good point.

But in the case of NUnit, it's not only a library; scripts are also provided. Shouldn't the configuration phase allow a flag for preventing the install of those scripts?
Comment 7 Matthias Mailänder 2013-02-23 04:17:35 UTC
I submitted a pkg-config file to upstream https://github.com/icsharpcode/SharpZipLib/pull/7
Comment 8 Miguel de Icaza [MSFT] 2013-02-23 09:15:21 UTC
Ok, can you post the before/after assemblies?

Even better, can you run an API diff tool to validate that there are no differences?
Comment 9 Matthias Mailänder 2013-02-23 11:24:21 UTC
I don't know what to diff and how to do it.
Comment 10 Andres G. Aragoneses 2013-02-23 11:26:23 UTC
You can maybe use the tool "mono-api-info".
Comment 11 Miguel de Icaza [MSFT] 2013-02-23 14:01:40 UTC
For now the before/after assemblies will do.
Comment 12 Matthias Mailänder 2013-02-24 03:39:29 UTC
https://gist.github.com/Mailaender/5023135/revisions is a diff between Mono/mcs/class/lib/net_4_5/ICSharpCode.SharpZipLib.dll and Mono/mcs/class/compat/net_4_5/ICSharpCode.SharpZipLib.dll from my branch.

Breaking changes are also indicated at https://github.com/icsharpcode/SharpZipLib/wiki/Release-History
Comment 13 Matthias Mailänder 2013-02-24 03:47:07 UTC
There are no mono-api-info changes between Mono/mcs/class/compat/net_2_0/ICSharpCode.SharpZipLib.dll from my branch and /usr/lib/mono/compat-2.0/ICSharpCode.SharpZipLib.dll from Mono 3.0.3 provided by openSUSE.
Comment 14 Matthias Mailänder 2015-05-02 02:47:34 UTC
You removed /usr/lib/mono/compat-2.0/ICSharpCode.SharpZipLib.dll in Mono 4.0 so I guess this does not apply anymore.