Compiling VS 2005 Beta2 to a mounted network share

Compiling VS 2005 Beta2 to a mounted network share

• Ragin Cajun

  also, in case anyone cares, I located the change that caused this issue. it is a fix for a potential security issue and crash.

  TANSTAAFL

  cheers,

  josh

  
  
  

• Pieter M

  [I entered the info below into the bug report, but I thought I'd also paste it here so more ppl might see it]:

  here is the analysis of the problem, for those interested, and some possible work-arounds. it is based on the only repro case that we have, so it may or may not apply to all instances of this problem. thanks go to the folks who helped with this (Zak Kramer et al)

  the situation appears to be:
  1. DEVENV - running as <local machine>\<user>
  2. Mapped Drive - Writing/Reading from the server using <domain>\<user>
  
  You have access to the file share since you have set up the mapped drive and your domain account has rights to write to the folder on the server.
  
  Now, when you start a build DEVENV will write the RSP file to the share. You have permission to do this because of the domain credentials for the mapped drive. When DEVENV does that CreateFile API call (<http://msdn.microsoft.com/library/default.asp url=/library/en-us/fileio/base/createfile.asp>) they pass an lpSecurityAttributes parameter. This specifies what users have access to this file. In this case they grant the local administrator (in this case the server’s admin group) and the current user that dev env is running as. Now, the problem is that the domain machine has no knowledge of the local user. Each user has a unique SID. This SID is what is used when we set the security.
  
  After that the compiler comes along and attempts to read the file. The file is one the mapped drive so your domain credentials are used. However your domain user’s SID does not equal the local user SID and is not in the server’s admin group so the access is denied.
  
  This whole issue grows out of the fact that the C++ build does not support network builds as disucussed in:
  
  255252 INFO: Accessing and Building Projects Over a Network Through Visual C++
  <http://support.microsoft.com/ id=255252>
  
  possible work-arounds:
  
  1. Build local - Obvious, but is an option in some cases
  2. Log on as the domain user
  3. Move your domain users into the Admin Group on the server - This will mean that they are in the Access Control list for these temp files since we also allow the server Admin’s to have rights to the files.
  4. Launch Visual Studio as the Domain User - This is a pretty neat trick. It basically extends what you are doing with the mapped drive to the Visual Studio process. There are a couple of ways that you can set this up:
  a. RunAs from the shortcut - Basically this is done by right clicking on the VS.NET shortcut and selecting RunAs
  b. Create or alter a shortcut to always RunAs the Domain User - With this you can alter the current or create a new one. Here is an article that discusses this:

  294676 How To Enable and Use the "Run As" Command When Running Programs in
  <http://support.microsoft.com/ id=294676>
  c. Create or alter a batch file to launch devenv as a domain user - This can be done with RunAs.Exe:

  Runas.exe
  <http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/runas.mspx>
  
  Now, the one drawback that we first noticed when using the RunAs is that you do not have the Mapped Drive at this point. This is because when Windows does RunAs it loads up the profile of that user. This article talks a bit about this:
  
  303308 Cannot Use Runas.exe to Run Remote Programs on Mapped Drives
  <http://support.microsoft.com/ id=303308>
  
  There is a simple workaround for this and that is to simply map that drive under that profile or you can use the UNC path. Finally, once you launch VS.NET you can map the drive from the Open Menu. Just navigate to the server. Right click on the folder and select “Map Drive” and then reconnect at logon.

  I hope that information is useful. we are continuing to look for ways to address this problem.

  josh

  VC++ project system developer

  
  
  

• bigshop

  We have the same problem here and would very much appreciate a solution.
  We are quite happy developing with our projects and source on our server and have no wish to change (projects are only accessed by one person at a time and ALL files are on the server so time stamps problems should be irrelevant).
  Why should time stamps be more of a problem with VS2005 than previous versions anyway
  
  PLEASE come up with a solution.
  
  
  

• CoolDeep

  I'm using VC++ 2005 Express and I get the same problem.  I assume the VS2005 Beta became the Express products, so no, the problem is still there.
  
  

• Rayven

  Are you still seeing this behavior with more recent builds If you can try this scenario with an RC1 build (available on MSDN), you might find that we've already fixed it.
  
  

• Definite Reaction

  Thanks Boris.  If you find something, could you email me (I don't read this board regularly).  kessler atsign cs dot utah dot edu
  
  We use network shares because that is where our students store their files.  If we used local directories, then they have to spend time copying files back and forth from the lab machines.  If there is a better solution than using a network share, I'd certainly love to hear about it.
  
  Bob.
  

• MaxMan1

  Hi Ronald,
  
  I've been experimenting with a system created using Virtual PC (we are contemplating offering a VPC system to the students with their stuff preloaded and ready to rock and roll).  I haven't tried the roaming profile idea (I assume that you mean that the students would just leave their files on their desktop).
  
  I did try mounting the drive and then setting up the solution directory under "work offline".  This didn't change what VS.Net did   It still fails with the same error saying that it can't find the file that it just tried to write.  Assuming that when you say shadowed folders, synchronized directories is the same thing, then that doesn't work.
  
  I'll muck around with a roaming profile next.
  
  Thanks again.
  Bob.
  

• maypo

  A followup - is that it doesn't fail when using VS 2003   The only thing that I noticed in the build log is that the name of the temporary files is now longer   Attached is a version that works using VS 2003.
  
  Thanks.
  Bob.
  
  

  Creating temporary file "u:\testconsole2003\Debug\RSP000001.rsp" with 
  contents [ /Od /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_MBCS" /Gm /EHsc 
  /RTC1 /MLd /Yu"stdafx.h" /Fp"Debug/testconsole2003.pch" /Fo"Debug/" 
  /Fd"Debug/vc70.pdb" /W3 /c /Wp64 /ZI /TP .\testconsole2003.cpp ] 
  
  
  Creating command line "cl.exe @u:\testconsole2003\Debug\RSP000001.rsp 
  /nologo" 
  Creating temporary file "u:\testconsole2003\Debug\RSP000002.rsp" with 
  contents [ /Od /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_MBCS" /Gm /EHsc 
  /RTC1 /MLd /Yc"stdafx.h" /Fp"Debug/testconsole2003.pch" /Fo"Debug/" 
  /Fd"Debug/vc70.pdb" /W3 /c /Wp64 /ZI /TP .\stdafx.cpp ] 
  Creating command line "cl.exe @u:\testconsole2003\Debug\RSP000002.rsp 
  /nologo" 
  Creating temporary file "u:\testconsole2003\Debug\RSP000003.rsp" with 
  contents [ /OUT:"Debug/testconsole2003.exe" /INCREMENTAL /NOLOGO /DEBUG 
  /PDB:"Debug/testconsole2003.pdb" /SUBSYSTEM:CONSOLE /MACHINE:X86 
  kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib 
  shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib 
  .\debug\stdafx.obj .\debug\testconsole2003.obj ] 
  Creating command line "link.exe @u:\testconsole2003\Debug\RSP000003.rsp" 

  
  

• Vikas1111

  I am having the same issue using VS2005 profession from a mounted drive.
  
  Apparently this is not *fixed*.
  
  
  As for me doing things and compiling from mouted drives makes some sense right now.
  
  
  

• Devo

  You can use roaming profiles or shadowed folders to achive the same goals. They can sync on logon and on logoff.
  
  Ronald Laeremans
  Visual C++ team
  

• cnuk

  I am investigating your issue but I should add that we do not really support working with projects over UNC shares. The reason is that file timestamps are near impossible to synchornize and this can cause many build problems.
  
  Thanks,
  
  

• Anuj Purwar

  On a project that is build locally, I get the Rebuild error:

  Could not delete file "c:\dev\repo_utils\ruby\wrappers\release\vc80.idb." Make sure that the file is not open by another process and is not write-protected.

  My environment is fully patched XP Pro and VS 2005 (SP 050727-7600). I do not get the error when I Build, only with a Rebuild. The error goes away when I change project Properties, Configuration Properties, General, and then change Intermediate Directory from $(ConfigurationName) to $(temp)\$(ProjectName)\$(ConfigurationName).

  Thanks,

  -Brian

  
  

• fudata

  I'm running into this same problem.  My scenario is as follows:

  I have a desktop machine and a laptop machine.  I frequently develop on the laptop at remote locations, so I choose to keep all of my code files on that machine and access them through my network when I'm at home and working on the desktop.  That way I always have the latest versions of all of my code, and I don't have to worry about copying files between machines and synchronizing file changes since I'm always working from the same set of files.

  With VS 2005 I'm able to compile a C++ project on the laptop, but I'm unable to compile the exact same code on the desktop due to the fact that I'm accessing it through a mapped drive.

  Is there an environment variable or something that needs to be set   This works perfectly for other VS projects (C#, VB, VB6, etc) and I've worked this way for 6 years with no problems.  We've done very few C++ projects so this problem may have existed in previous VS editions but I've just recently run into the problem with a C++ project I'm working on.

  
  

• JohnCBisys

  We are looking at this issue now. You can track the progress at the following URL. Please vote on this bug if it affects you.

  http://lab.msdn.microsoft.com/ProductFeedback/viewFeedback.aspx feedbackid=8fb28ec3-897a-4467-a2ca-6e11d7c324ac

  Thanks,

  
  
  
• Compiling VS 2005 Beta2 to a mounted network share