Our build server (running Windows 2003 Server) was set up with 2 partitions: a small system partition (C:) and a large data partition (D:). As we installed more and more software packages on it, the system drive filled to capacity. In order to free space on the system partition, we moved a variety of directories from drive C to drive D, and then used the Junction utility from SysInternals (now owned by Microsoft) to create reparse points on drive C that pointed to the new file locations on drive D. A reparse point is a symbolic link that redirects a file request from one point to another on the same computer. In this case, the reparse points allowed applications to access files supposedly on drive C, while in fact they were on drive D. Storage problem solved, all was well...or so we thought.
This storage reconfiguration strategy can be successfully applied for user profiles (via C:\Documents and Settings\) and a variety of applications that install to C:\Program Files by default. However, our decision to redirect file requests for the Global Assembly Cache (located at C:\Windows\Assembly) blew up in our faces when the most recent Windows security update (KB 928365, which corresponds to security bulletin MS07-040) was installed. After the build server was rebooted, we suddenly started seeing the following error show up in a variety of contexts:
Could not load file or assembly 'System.EnterpriseServices, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
Web services and web applications running in ASP.NET 2.0 threw this error on first request, and Visual Studio 2005 builds/compiles would report this error as well. We tried a variety of troubleshooting steps, such as rolling back the security update, and reinstalling .NET Framework 2.0, but nothing worked...that is, nothing worked until we removed the reparse point for the GAC. Once we moved the GAC's physical file location back to C:\Windows\Assembly, everything suddenly began to function correctly.
Evidently there is some kind of security setting in the .NET Framework which does not allow updates to some (or all) of its assemblies anywhere outside of the original GAC location. For the time being, I do not have the time to satisfy my curiosity by researching why this is so. However, I do have a few minutes to warn my readers not to fall into the same trap: do not create a reparse point for the GAC folder!