# Error D8022 - can't open .RSP file

• ### Question

• I am getting the same error as the post

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=147591&SiteID=1

(Compiler gives.... "1>cl : Command line error D8022 : cannot open 'j:\<project path>\Debug\RSP00000143164944.rsp'"

[J: is a network drive, and I've substituted "<project path>" for a list of directories]

I suspect the answer is in that post, but I can only see replies up until the 2 Dec 2005 - whereas the header indicates hte last reply was 31 Dec 2005. (I can't see how to view any more replies - apologies if it's obvious!).

Paul

Thursday, September 25, 2008 8:33 AM

• Don't bother, it doesn't get any better.  There was some kind of issue with network drives, although I don't think it was with .rsp files.  My memory fails me.  Nobody does this, dumping megabytes worth of .pch and .obj files through a network is just not a good idea.  Add a postbuild step if necessary to copy only the important files.
Friday, September 26, 2008 12:38 AM

### All replies

• Don't bother, it doesn't get any better.  There was some kind of issue with network drives, although I don't think it was with .rsp files.  My memory fails me.  Nobody does this, dumping megabytes worth of .pch and .obj files through a network is just not a good idea.  Add a postbuild step if necessary to copy only the important files.
Friday, September 26, 2008 12:38 AM
• Hello. I have the same problem. The project resides on a network drive and that's where the compiler output is being sent. This works fine on my machine, but when I try mapping the same network drive and compile from a virtual machine I get the D8022 error.
This RSP file does not exist in the output directory, is it something that gets created as a part of the build procedure ?? If I change the output folder to my local drive would that make any difference ??
Thanks.
Monday, April 6, 2009 5:58 PM
• The problem appears to occur when you use an account with limited user rights to map the network drive.  If you use an account with Aministrator privileges to mount the network drive, the problem should go away.

Arguably, this is an ugly solution.  However, I could find no other way to solve the problem.
• Proposed as answer by Thursday, September 3, 2009 5:38 PM
Thursday, September 3, 2009 5:37 PM
• This works fine on my machine, but when I try mapping the same network drive and compile from a virtual machine I get the D8022 error.
Are you using an account with limited privileges in the VM to map the network drive?  Try using an account with Administrator privileges.
Thursday, September 3, 2009 5:39 PM
• Nobody does this, dumping megabytes worth of .pch and .obj files through a network is just not a good idea.
I think lots of people who use VMs for builds do this.  If the VM is connected to the share via a virtual network, then the amount of network traffic is irrelevant.  If the VM is connected to the share via a LAN with 100 MB or 1 GB bandwidth, once again, the amount of network traffic is irrelevant.
Thursday, September 3, 2009 5:44 PM
• DavidPrime, since you posted this solution in 2009, do you know if any other solution has been found other than using a local Admin account?

I recently had the D8022: cannot open 'y:\...\...\...\RSP00000131883221.rsp' in cl(0, 0)

error with MSBUILD.  I am running a build VM in an isolated LAN that maps a network share drive (to y:) using a local account (not domain account).

Thanks.

Thursday, September 22, 2011 1:56 PM
• It's a black magic... I've found a simple workaround.

I had two projects on the network drive, one of them had this error and another - no. It was funny to find in build log that VS2005 is trying to create RSP file in my temp folder, not on the network drive, so it leads to successful build:

"Creating temporary file "C:\Users\<UserName>\AppData\Local\Temp\RSP00000235802952.rsp" with contents..."

After lots of time spent on comparing project files, I've found the reason. I only added backslash to the end of Intermediate Directory (Project Properties->General), and everything became compilable!

So, for example:

..\..\..\int\$(ConfigurationName)\ instead of: ..\..\..\int\$(ConfigurationName)

And the intermediate files are in the same place as before, by the way.

It's a really amazing workaround, maybe a result of bug, but everything works now. Hope it will help somebody.

• Edited by Friday, August 24, 2012 3:20 PM
• Proposed as answer by Thursday, November 29, 2012 11:37 AM
Friday, August 24, 2012 3:20 PM