I recently encountered the exact same problem after converting one of our solutions to Visual Studio 2010.
Analysis has demonstrated that if two consecutively compiled projects invoke gacutil
in their post-build steps, and the second project is small enough, and the build machine is fast enough, then the second invocation of gacutil
would systematically fail with an "Access denied" error.
That looked like a race condition of some sort, but we could not determine the exact root cause. Blocking the post-build steps with a busy loop while there was an instance of gacutil
running did not change the situation.
In the end, we were able to solve the issue by using version 4.0 of gacutil
instead of version 3.5. We changed all calls in our post-build steps from:
"$(FrameworkSDKDir)Bin\gacutil.exe" /if "$(TargetPath)" /nologo
To:
"$(FrameworkSDKDir)Bin\NETFX 4.0 Tools\gacutil.exe" /if "$(TargetPath)" /nologo
After applying these changes, gacutil
did not fail again during builds.