DotNetZip.Semverd
DotNetZip.Semverd copied to clipboard
Please change the assembly name back to Ionic.Zip.dll
This seems like a bad decision:
- There is no way of writing a bindingRedirect to an assembly name that has changed so existing applications that use our framework may break.
- The main namespace of the library is Ionic.Zip which one would expect the library to be Ionic.Zip.dll
- It adds no apparent value to change the name, so why change it
I very much appreciate this library, just questioning why the name change.
The value added is that it allowed us to automate the release process. Which is a huge value add since now suddenly we can have bugfix releases. I'm sorry about the churn, but the change was made three years ago and you're unfortunately too late to the party to influence that decision.
the change was made three years ago and you're unfortunately too late to the party to influence that decision
I'm not sure I understand this? The change was made in the last release. As of 1.10.0 it was still Ionic.Zip.dll.
Fair point...
Any chance this is going to be fixed? Assembly binding does not let you redirect to a different assembly name, so plugins that were relying on Ionic.Zip.dll will now have to recompile against DotNetZip.dll.
Also, it looks like the "Zip DLL.csproj" project is the only one that changed. The "Zip Reduced.csproj" is still producing Ionic.Zip.Reduced.dll and "BZip2 DLL.csproj" is still producing Ionic.Bzip2.dll.
Changing from Ionic.Zip.dll to DotNetZip.dll, seems like an unwarranted change. Thoughts?
This is also going to be breaking for me. I'm surprised this isn't affecting more people.
@jonreis @nickjudson I think either people stop upgrading or they recompile with the new name. At this point (a bit more than half a year later), it's getting too late again. I would have expected a pull request, when I reopened.
Despite this, I'm actually really curious; why can't you recompile your software over the time-scale of half of years?
Hi @haf,
The scenario is this. We have a plugin architecture where users build plugins. We supply some functionality to the plugin developer like compression/decompression. In our app.config we have a binding redirect such as
<dependentAssembly>
<assemblyIdentity name="Ionic.Zip" publicKeyToken="6583c7c814667745" culture="neutral" />
<bindingRedirect oldVersion="1.9.0.0-1.99.0" newVersion="1.10.0.0" />
</dependentAssembly>
When we upgrade the version of Ionic.Zip we change the binding redirect to point to the latest version of the assembly. When a plugin goes to use the same assembly the binding redirect ensures that both the plugin and our product are using the same version.
If we upgrade to the new DotNetZip.dll, then our customers also have to recompile their plugins against the DotNetZip.dll, thus a breaking change. Plugins from previous releases will no longer work in our product because they will be looking for Ionic.Zip.dll which no longer exists.
Just curious what the justification was to change the name, and only in the one project?
This also affects a project we are working on, constituting an onerous breaking change. I also don't get what the assembly name has to do with automating a release process? If the issue was distinguishing between a "DotNet" version and a "Java" version (assuming that is what you are getting at), wouldn't the extension of the artifacts be enough (.dll vs. .jar)?
Anybody found a workaround for this? After upgrading, VS 2019 compiles with DotNetZip correctly. But when building using MSBuild from command line, I get type or namespace 'Ionic' could not be found.
@sthomas1618 perhaps you can fix the compile error and send a pull request?
The reduced DLL is still called Ionic.Zip.Reduced, so this seems inconsistent. I'd prefer if it just went back to the original names for both, but at this point no matter what you do it'll break someone.
We don't go back to the original names because the DLLs should match the nuget and project names.
Actually you can change file names when doing a bindingRedirect:
<dependentAssembly>
<assemblyIdentity name="Ionic.Zip" publicKeyToken="6583c7c814667745" culture="neutral" />
<bindingRedirect oldVersion="1.9.0.0-1.99.0" newVersion="1.10.0.0" />
<!-- <codeBase version="1.9.0.0" href="Ionic.Zip.dll" /> -->
<codeBase version="1.10.0.0" href="DotNetZip.dll" />
</dependentAssembly>