views:

130

answers:

2

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.

+4  A: 

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...

codeape
+3  A: 

If it wasn't clearly documented that the installation put the assemblies in the GAC, then I would fault the developers/packagers of the software. If it was clearly documented, then I would fault the sysadmins who installed the software for not understanding the implications of the install.

Under most circumstances I would think that installing in the GAC would be unnecessary -- and I personally don't -- but I suppose there could be some situation in which it seems like the most reasonable solution. It's also possible that they merely packaged another installer with theirs as the easiest way to ensure that their dependencies have been met. Not ideal, but an understandable decision if their expectation is that the software would be normally be installed on standalone servers.

tvanfosson