Building .NET Projects with the Correct References

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 <your project>.vbproj or <your project>.csproj.

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 <your project>.vbproj.user and <your project>.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 <your project>.vbproj.user and <your project>.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.