| Author |
 Topic  |
|
|
tcassisi
Junior Member
14 Posts |
 Posted - Oct 10 2006 : 05:06:16 AM
|
One way to reduce the length of development utility path/file messages is to use the old "subst" command to replace long paths with a drive.
This has the side benefit of allowing easier migration of custom build activities (that often involve fixed paths) between machines or users as well as providing a consistent CodeView entry within the binaries that points to the PDB symbol file without giving away private information.
In build 10.3.1538, I've noticed that when pressing Alt-G, I see both the Subst path as well as the full underlying path as follows:
Z:\\MyProduct\\Header.h
C:\\Documents and Settings\\Name\\Microsoft\\Visual etc\\MyProduct\\Header.h
Ideally all pathspec's should be run through the QueryDosDevice Win32 API call to resolve the Z:\\ to the full path, thus eliminating the duplicates. |
|
|
feline
Whole Tomato Software
United Kingdom
19004 Posts |
Posted - Oct 10 2006 : 07:39:10 AM
|
which IDE are you using?
is your system configured to only see the Z: paths, or does it also have instances of the longer C: paths?
it is possible VA is seeing this single file in two different places, and thus is picking up both names that way. |
zen is the art of being at one with the two'ness |
 |
|
|
tcassisi
Junior Member
14 Posts |
Posted - Oct 10 2006 : 11:15:36 AM
|
This is Visual Studio .NET 2005. Nothing unusual has been done to the system, meaning that the Z: is simply added via a subst and the solutions/projects are opened off the Z:\\ path.
One possibility is that by using #include <header> in conjunction with #include "./header" that the former is picking up the full C:-path as the project/solution folder rather than the Z:\\ abbreviated path.
There are no hardcoded full paths within #include lines.
Hence my suggestion to run the pathspec through the relevant Win32 call to eliminate duplications, admittedly a rather brute force approach, but one used in the MSDN examples relating to querying file names from handles for e.g.
|
|
|
|
feline
Whole Tomato Software
United Kingdom
19004 Posts |
Posted - Oct 11 2006 : 09:56:39 AM
|
what i am thinking about is things like the C++ additional include directories setting in the project. from my experience the solution files tend to store relative directories, but this does not stop people hard coding directory paths.
which OS are you running? i have just done a couple of quick tests using the "Map Network Drive" feature of windows explorer, which should have a similar result, and when I try to access the new drive letter VS2005 instantly crashes without even giving me an error message *sigh*
I think this crash may be related to using win2k inside a virtual machine. I recall something about not being able to map network drives to directories that are down a directory tree under win2k, and I am trying to map Z:\\ drive to a "network" drive, since this is where most of my source code lives. |
zen is the art of being at one with the two'ness |
Edited by - feline on Oct 11 2006 12:23:52 PM |
|
|
|
jpizzi
Tomato Guru
USA
642 Posts |
Posted - Oct 11 2006 : 11:43:57 PM
|
The subst command is much simpler to use than map network drive for what the OP is doing. I thought that "junction" points were a new feature of XP, so I wouldn't expect mapping a network drive down into a directory tree to work. I find it disturbing that 2000 allowed you to think you were doing that.
I use the subst trick all the time at my regular job.
For those of you who remember the subst command of DOS, the problems with it are gone. The subst of NT and above is very stable and nice.
Not that any of this discussion has much to do with the original problem. |
Joe Pizzi |
|
|
|
tcassisi
Junior Member
14 Posts |
Posted - Oct 12 2006 : 04:47:12 AM
|
Yes, if you map local drivers via the network mechanism, things like MSI will mysteriously fail, even if the service is aware of the drive mapping, whereas "subst" works.
Until Vista, using features of NTFS is not a good idea, as Explorer cannot deal with them, and occasionally will crash depending on what is used.
The "subst" technique, as I mentioned in my first posting, is actually just a fully supported mechanism for dealing with the legacy concept of a drive specification -- these days, it really is the UNC-style convention, which can identify all types of "things" including Mutexes for example.
---
Back to topic: I closed everything down, manually deleted the Visual Assist's vs8 folder, and restarted everything - being sure that all solutions were opened from the subst (z:\\) drive.
So far, I've not had a reoccurrence of the issue; if it happens again, would saving the entire vs8 folder assist in finding out more? |
|
|
|
feline
Whole Tomato Software
United Kingdom
19004 Posts |
Posted - Oct 12 2006 : 07:26:31 AM
|
it might.
my initial suspicion is that either the IDE or you opened one of these files via the full path, rather than the Z: drive. however this is just a guess.
certainly if this starts happening again the more clues you can provide the better.
jpizzi do you tend to open projects from these drive letters? if so, have you ever run into this problem of VA listing both paths to a file? |
zen is the art of being at one with the two'ness |
|
|
|
jpizzi
Tomato Guru
USA
642 Posts |
Posted - Oct 13 2006 : 12:18:53 AM
|
I have opened projects from these drives. The only time I had a file listed twice was when I accidently opened a file via the raw drive (for example, double-clicking on it in an explorer window from the "wrong" drive).
I am betting your guess is right. But, unless it happens again, we are not likely to find out. C'est la vie. |
Joe Pizzi |
|
|
| |
Topic |
|
Duplicate definitions when using Subst - 10.3.1538
