Assembly rename is a bad idea

Aug 27, 2012 at 7:43 PM

Renaming the DLL was a bad idea. Other projects that reference it will be broken now. Since the name of the assembly is part of it's identity, a bindingRedirect does not work.  Changes like this should be avoided in the future.

Aug 27, 2012 at 8:02 PM

Absolutely agree that changes like this are to be avoided. But it was an even worse idea in the past to have the strong names of the DLL and the EXE be identical. That had to be changed. The bad decision in the past finally forced my hand.

I tested a project using the old Nuget package, updated the Nuget, and the project references were all automatically cleared up effortlessly. Lesson: use NuGet and things like this aren't a problem for your projects. Granted, not every can (or wants to) use Nuget, so I had also tested a project that simply referenced the DLL directly, and yes: that did break. The reference to AjaxMin.dll could not be resolved (obviously) and it had to removed and a new reference to AjaxMinLibrary.dll added. Unfortunately, I just couldn't avoid that issue.

So yes: I totally agree with you. This strong-name conflict has been an issue literally for years, and I hadn't resolved it until now precisely because of this whole existing-project-reference problem. But it was time, what with all the restructuring and addition of support for multiple .NET versions. The names of those assemblies had to be different, and now they are. Believe me: I didn't do this on a whim or without realizing the impact it would have; this was a long, hard decision that has been in the works for a very long time. I apologize for the inconvenience it causes.

Aug 27, 2012 at 9:47 PM
Edited Aug 27, 2012 at 9:47 PM

I am using Bundle Transformer from NuGet.  I have submitted a request for them to update a new package with a link to the new assembly name.

What done is done. I just wanted to raise the issue as some people do not understand the consequences of their actions.  However, you do understand consequences.  In the 4.61 release notes you call out 'BIG CHANGES', however, the assembly name change is a 'BREAKING CHANGE'.  Unfortunately, when I upgraded via NuGet, I had no way of knowing it was going to be a breaking change.

Thanks for you hard work on this project. We do appreciate your efforts.


Aug 27, 2012 at 9:49 PM

Completely right: should've been labeled a "breaking" change. Excellent point taken. I'll edit the description right now.

Sep 4, 2012 at 2:46 PM

This really should have been done with a major version change.  It is completely screwing up other NuGet packages that use this library.

Sep 4, 2012 at 2:53 PM

An even better point. How about I branch the code, have this new code in version 5, and roll-back all changes in the version 4 code?

Sep 4, 2012 at 5:20 PM

Okay, I have seen the error of my n00b ways, and I apologize for making such a dumb mistake. It won't happen again.

I have released version 4.63. The Nuget package has the .NET 2.0 version named AjaxMin.dll -- this new package should not break any existing projects or other dependent packages. If it does, please let me know right away and I'll try to get it fixed.

I have also updated the MSI to not only include the new .NET 4.0 "AjaxMinLibrary.dll," but also the older .NET 2.0 "AjaxMin.dll," should people be referencing it in that manner. Hopefully, again, this won't break any existing people out there.

Sep 4, 2012 at 5:22 PM

I just keep digging myself deeper and deeper, don't I? Some other projects have already updated to the AjaxMinLibrary.dll. So my "fix" will break them. Give me a minute or two -- I'll update the NuGet package once more so it will support the people who quickly adapted to the breaking change. Big learning experience.

Sep 4, 2012 at 7:19 PM

Okay, I just released 4.64. This nuget package includes DLLs for three different .NET versions:

  • .net 2.0 - AjaxMin.dll (same .net version and DLL name as previous versions, at or before 4.60)
  • .net 3.5 - AjaxMinLibrary2008.dll (new .net version support, new name)
  • .net 4.0 - AjaxMinLibrary.dll (new .net version support, new name)

The theory here is that if an existing package links to AjaxMin.dll, they should continue to work because AjaxMin.dll is defined in the nuget package under the .net 2.0 folder. If an existing package was on top of my flailings and already updated to my recent breaking dll-name update, and now links to AjaxMinLibrary.dll, they too should continue to work, because that DLL is in the nuget package (assuming they don't support only .net 2.0).

Does this work? If it doesn't, I just don't see any way out of this other than going back to a nuget package that only contains lib/net20/AjaxMin.dll, which is what I had in version 4.60 and earlier. That will keep older packages working, but would break [again] new packages that already updated to the last breaking change; those packages would have to go back to the old name to not be broken anymore.



Sep 4, 2012 at 9:25 PM

I don't think it's going to work that way. I think a project is going to link to AjaxMin.dll only if it's set up for .NET 2.0. Well, crud. Anyone have any ideas on how I can get out of this mess? All I see is releasing a new package with only AjaxMin.dll as the library, like it used to be. But then other packages who have adapted to my breaking change will be broken again. Thoughts?

Sep 6, 2012 at 8:48 AM

It sounds like some people will be upset no matter what you do, so I guess you have to go for the option that upsets the fewest people.

Sep 6, 2012 at 3:59 PM

too true.