Question

Scenario: We have a server where there are multiple ASP.NET websites hosted on it. A few days ago quite a few of these websites “broke” with the following error:

Warning 44 Could not resolve this reference. Could not locate the assembly “AjaxControlToolkit, Version=1.0.10920.32880, Culture=neutral, PublicKeyToken=28f01b0e84b6d53e, processorArchitecture=MSIL”. Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.

After some investigation it appears that a (commercial) CMS system had been installed on the server and that this had added the 3rd party AjaxControlTookit to the Global Assembly Cache. It didn’t ask, it just added it (in fact, it added two versions: 1.0.10618.0 and 3.0.20229.0). This was causing resolution conflicts as the websites in question where referencing a different version of the Toolkit in their local /Bin directory.

So, I guess my question is: Do you think it was acceptable for this CMS to install these assemblies in the GAC (especially given that the assemblies were open-source libraries and not their own)? Or are the websites that “broke” at fault for somehow not being more explicit in how they referenced assemblies in the /Bin folder? Thanks.

Answer 1

No, I do not think it is acceptable.

The assembly should have been put in the application’s bin folder.

An installer should make changes as local as possible.

In many cases, the best installer is no installer at all. At least for server-side applications. I would much rather have a zip file + INSTALL.txt saying:

1. System requirements: IIS, ASP.NET 2.0, SQL Server 2005
2. Create new empty directory
3. Unzip contents into directory
4. Create IIS virtual directory pointing to directory
5. Execute the foo.sql file to create the database
6. Configure the database connection string in web.config

I once saw Windows Installer described as: “The militant right wing of the Windows registry.” Found that quite funny…