bug with Visual Studio.NET pro - building on network share broken

[Gianni Mariani]

I cracked open my vstudio .NET pro and tried to build some old sources.

I created a new project and to my amazement I could edit the files but
the compiler could not find them.

OK, so I created a virtual drive (net use x: \\share\blah) and opened
the exact same vcproj file and viola, all was fine.

Devstudio 6.0 worked fine in this environment so IMHO this is a pretty
major regression.

This is the build log of the failed build....

*Notice that the source file name is created incorrectly...*

=================================================================================
Build Log


------- Build started: Project: fooproj, Configuration: Debug|Win32 -------

Command Lines


Creating temporary file
"\\uluru\gianni\limbo\devenvfoo\foo\projects\fooproj\fooproj\Debug\RSP000003.rsp"
with contents
[
/Od /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_MBCS" /Gm /EHsc /RTC1 /MLd
/Fo"Debug/" /Fd"Debug/vc70.pdb" /W3 /c /Wp64 /ZI /TP
i\limbo\devenvfoo\foo\src\foo.cpp
]44
Creating command line "cl.exe
@\\uluru\gianni\limbo\devenvfoo\foo\projects\fooproj\fooproj\Debug\RSP000003.rsp
/nologo"

Output Window


Compiling...
foo.cpp
c1xx : fatal error C1083: Cannot open source file:
'i\limbo\devenvfoo\foo\src\foo.cpp': No such file or directory

Results


Build log was saved at
"file://\\uluru\gianni\limbo\devenvfoo\foo\projects\fooproj\fooproj\Debug\BuildLog.htm"
fooproj - 1 error(s), 0 warning(s)

===============================================================================

This time:

EXACTLY the same files, this time opened as j: instead of \\uluru\gianni


===============================================================================

Build Log


------- Build started: Project: fooproj, Configuration: Debug|Win32 -------

Command Lines


Creating temporary file
"j:\limbo\devenvfoo\foo\projects\fooproj\fooproj\Debug\RSP000006.rsp"
with contents
[
/Od /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_MBCS" /Gm /EHsc /RTC1 /MLd
/Fo"Debug/" /Fd"Debug/vc70.pdb" /W3 /c /Wp64 /ZI /TP
\limbo\devenvfoo\foo\src\foo.cpp
]
Creating command line "cl.exe
@j:\limbo\devenvfoo\foo\projects\fooproj\fooproj\Debug\RSP000006.rsp
/nologo"
Creating temporary file
"j:\limbo\devenvfoo\foo\projects\fooproj\fooproj\Debug\RSP000007.rsp"
with contents
[
/OUT:"Debug/fooproj.exe" /INCREMENTAL /NOLOGO /DEBUG
/PDB:"Debug/fooproj.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\foo.obj
]
Creating command line "link.exe
@j:\limbo\devenvfoo\foo\projects\fooproj\fooproj\Debug\RSP000007.rsp"

Output Window


Compiling...
foo.cpp
Linking...

Results


Build log was saved at
"file://j:\limbo\devenvfoo\foo\projects\fooproj\fooproj\Debug\BuildLog.htm"
fooproj - 0 error(s), 0 warning(s)


=========================================================================

 

[David Lowndes]

I created a new project and to my amazement I could edit the files but

the compiler could not find them.

OK, so I created a virtual drive (net use x: \\share\blah) and opened
the exact same vcproj file and viola, all was fine.

Gianni,

The same issue seems to exist with the current Whidbey alpha tools, so
I'll pass this on to MS.

Dave

 

[David Lowndes]

The same issue seems to exist with the current Whidbey alpha tools, so

I'll pass this on to MS.

Hmm, when I try to a UNC path on my machine rather than a server, it
works OK, and the server path via a mapped drive letter still failed,
so it may be a permissions issue.

More investigation is needed to pin this down I think.

Dave

 

[David Lowndes]

I'm pretty sure it's a simple relative file name to absolute file name

mapping problem.

It doesn't seem to be that for me - both UNC and mapped drive letters
behave the same - but see below.

Examining things with SysInternals FileMonitor shows that the rsp file
is accessible by the devenv process, but not by the compiler (cl.exe).
I've no idea why.

I've been told by MS that the KB article :
http://support.microsoft.com/?id=255252

applies.

As far as I can tell, the KB article does not apply.

I think that's just a cop-out: "Use of Visual C++ in this manner is
not supported."

It also refers to VC6 & VC.Net and you mentioned that the problem
didn't exist with VC6 - can you re-verify that?

Anyhow, I have bugged my results.

I have been able to reproduce the problem on a single machine
referencing a local share.

I've attached a zip of a small project which exposes the problem. It
appears that if the vcproj file is not in the same directory as the
source files, then the relative to absolute file name mapping is broken
if there is no drive letter.

Oops - perhaps we're actually talking about subtly different problems.
I'd been testing with a "standard" Wizard generated project, and that
doesn't show a problem with local shares, however your example does -
with VS2003. The Whidbey alpha seems to be OK with it!

Dave

 

[Gianni Mariani]

....

Oops - perhaps we're actually talking about subtly different problems.
I'd been testing with a "standard" Wizard generated project, and that
doesn't show a problem with local shares, however your example does -
with VS2003. The Whidbey alpha seems to be OK with it!

That's good news. I wonder when I'll be getting my VS2003 service pack?

Thx

 

[David Lowndes]

That's good news.

Only partly. While it now works ok for UNC paths to the same machine,
it still fails (with a different error) on a shared networked drive on
a different computer.

Dave