Solution Converted from Visual Studio 2008 Fails Gacutil Post-Build Steps in Visual Studio 2010

3
votes

I have converted a .NET 2.0 solution containing multiple projects from Visual Studio 2008 (where everything build correctly) to Visual Studio 2010. I loaded the solution in Visual Studio 2010 running in Admistrator mode and selected "Build Solution". The build failed on some post-build steps in some of the projects:

Microsoft (R) .NET Global Assembly Cache Utility.  Version 3.5.30729.1
Copyright (c) Microsoft Corporation.  All rights reserved.

Failure adding assembly to the cache: Access denied. You might not have administrative credentials to perform this task. Contact your system administrator for assistance.
36>C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.Targets(3717,9): error MSB3073: The command ""C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\gacutil.exe" /i MyAssembly.dll" exited with code 1.

If I select these same projects, and build just the individual project, rather than the entire solution, then the gacutil command is successful.

The error message makes it sound as if permissions are the problem ("Access denied") but I have verified that Visual Studio 2010 is running in Administrator mode -- I see it in the title bar ("MySolution - Microsoft Visual Studio (Administrator)").

Why would gacutil fail when building the entire solution but succeed when just a single project in the solution is built?

1
visual-studio-2010visual-studio-2008gacutilpost-build

1 Answers

2
votes

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.