error RG0000: Could not load file or assembly 'xxx' or one of its dependencies. Access is denied
This is for a windows forms project under VS2010.
Here is the message I get from MSBuild:
error RG0000: Could not load file or assembly '3rdPartyAssemblyUsedByProject, Version=1.1.263.0, Culture=neutral, PublicKeyToken=687bce93d7ce902c' or one of its dependencies. Access is denied. Line 174 , position 5. [C:\xxx\src\BackOffice.csproj]
Here is the command line used to kick this off:
c:/WINDOWS/Microsoft.NET/Framework/v4.0.30319/msbuild.exe BackOffice.csproj /p:PlatformTarget=x86
Line 174 of the resx file that was attributed to the error:
<data name="generalImages.ImageStream" mimetype="application/x-microsoft.net.object.binary.base64">
<value>
...
</value>
</data>
generalImages is an ImageList control with images used for buttons on the form.
This works fine on my dev machine, but is a problem on my build server. My workstation is Windows 7 64-bit, the build server is Windows 2008 Server 64-bit. The build server does have the windows 7.1 sdk installed.
If I use msbuild from v3.5 framework, the compile completes successfully. I do get this warning message that is not causing me any problem at this point: Project file contains ToolsVersion="4.0", which is not supported by this version of MSBuild. Treating the project as if it had ToolsVersion="3.5".
The whole reason for this is to actually target the 4.0 framework and use things like method defaults, which do not work when targeting 3.5.
I have searched and searched on this one. I have come across a lot of hits related to 32-bit/64-bit issues -- where the image format is the problem, but this is not my problem. This error says "Access is denied". I did use fuslogvw to try to figure out where the access denied was coming from -- but I am not seeing that it is, but it is not actually finding any assembly. The assembly is not in the GAC, but in a tangential directory to the project file where the project file reference is.
Here is the fusion log:
* Assembly Binder Log Entry (8/30/2010 @ 1:44:48 PM) *
The operation failed. Bind result: hr = 0x80070002. The system cannot find the file specified.
Assembly manager loaded from: C:\Windows\Microsoft.NET\Framework64\v2.0.50727\mscorwks.dll Running under executable C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\ResGen.exe --- A detailed error log follows.
=== Pre-bind state information === LOG: User = domain\user LOG: DisplayName = 3rdPartyAssemblyUsedByProject, Version=1.1.263.0, Culture=neutral, PublicKeyToken=687bce93d7ce902c (Fully-specified) LOG: Appbase = file:///C:/Program Files/Microsoft SDKs/Windows/v7.1/Bin/ LOG: Initial PrivatePath = NULL LOG: Dynamic Base = NULL LOG: Cache Base = NULL LOG: AppName = NULL Calling assembly : System.Windows.Forms, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089. === LOG: This bind starts in default load context. LOG: Using application configuration file: C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\ResGen.exe.Config LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v2.0.50727\config\machine.config. LOG: Post-policy reference: 3rdPartyAssemblyUsedByProject, Version=1.1.263.0, Culture=neutral, PublicKeyToken=687bce93d7ce902c LOG: GAC Lookup was unsuccessful. LOG: Attempting download of new URL file:///C:/Program Files/Microsoft SDKs/Windows/v7.1/Bin/3rdPartyAssemblyUsedByProject.DLL. LOG: Attempting download of new URL file:///C:/Program Files/Microsoft SDKs/Windows/v7.1/Bin/3rdPartyAssemblyUsedByProject/3rdPartyAssemblyUsedByProject.DLL. LOG: Attempting download of new URL file:///C:/Program Files/Microsoft SDKs/Windows/v7.1/Bin/3rdPartyAssemblyUsedByProject.EXE. LOG: Attempting download of new URL file:///C:/Program Files/Microsoft SDKs/Windows/v7.1/Bin/3rdPartyAssemblyUsedByProject/3rdPartyAssemblyUsedByProject.EXE. LOG: All probing URLs attempted and failed.
At this point -- I am stumped. Not sure where to go next. Any advice would be welcomed.
Cort
Answer
It looks a lot like the known VS 2010 bug described here on blogs.msdn.com. If so, it seems that Microsoft have decided not to fix it until Visual Studio 11 at the earliest, and for many people (including us :| ) none of the workarounds mentioned in the post work. So good luck.