Geeks With Blogs
Chris Falter .NET Design and Best Practices

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=, 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!

Posted on Monday, July 16, 2007 8:31 AM .NET Gotchas | Back to top

Comments on this post: Do *NOT* Set up a Reparse Point for the Windows\Assembly Folder!

# re: Do *NOT* Set up a Reparse Point for the Windows\Assembly Folder!
Requesting Gravatar...
Ouch! Good to know.
Left by Will Pritchard on Jul 18, 2007 3:35 AM

# re: Do *NOT* Set up a Reparse Point for the Windows\Assembly Folder!
Requesting Gravatar...
Be careful when you use the Sysinternals junction utility, it expects the target directory to be empty when the junction is created. If the target directory is not empty it will throw out an error and delete the junction point it created which will also delete the target directory!
Left by Tony Low on Mar 26, 2008 2:09 PM

Your comment:
 (will show your gravatar)

Copyright © Chris Falter | Powered by: