Building projects with VS.NET 2003 (devenv.exe), you run into some hassles with the ReferencePath property. You can see this property in the project user file:
The problem is that only a full path is valid for this property. Not only that, but there can be a list of paths?even if you manually change the property value, VS may reconstruct it, so the end result may point to a location where no references exist. VS.NET reconstructs the paths each time you open a project after it finds the reference based on HintPath in
For example, suppose you’re using the Rational ClearCase configuration management system and mapping your views to drive letters. The full path with a drive letter that is “good” for one view may not be “good” for another view that is mapped to another drive letter.
There are a few ways to deal with this situation depending on your development environment:
- Do not use the
.vbproj.user and.csproj.user files at all. The files will be rebuilt each time you open your solution and you should just deal with it. - Do not keep the
.vbproj.user and.csproj.user under source control. Remember that if you use this solution, you may run into versioning problems. - Keep only one copy of the file to be referenced. This is not always practical.
- Reference to the projects in your solution instead of referencing to their output files. If you have a multi-group development, this can be impossible.
- Standardize the location for all references. For example, create a well-known bin directory and copy into it all the files from the output directories for the debug or release builds. To do this:
- If you use C#, create the post-build step.
- If you use VB.NET, create the add-in. VB.NET 2003 does not have the post-build steps.
- For automated builds, create the build script.
