I just saw Williams post about a bug in Visual Studio and thought I would do a follow up to the article I posted last week about discovering the same bug.
We have an agreement with some local MS consultants who were able to try to get some more information for us. It was recommended to us to follow the Team Development with Visual Studio.net and VSS white paper, as that paper gives us guidelines to avoid these dependency problems. The white paper suggests using project references as much as possible, implement a daily build processes that the assemblies are outputed to, and share that location so developers could pull the assemblies down, or require developers to build the assemblies locally on their machines. These steps are required as it is advised not to check the assemblies into VSS. They also suggestion to break your solutions up to logical groups so that you can create establish your project references. This becomes more and more difficult as you have a project that has 50 projects in it, and this is where we are. Right now the project we are working will end up having quite a number of projects, and we are doing our best to set them up to use project references but there are times where we are going to have to use file references and that is where the common output directory would be very helpful.
We also came up with a different solution that is working out well for us, that I don't believe is mentioned in the whitepaper, and that is to take advantage of the post build event in each project. In projects that we know are going to be referenced by another solution through a file reference, we setup a post build event to do an xcopy of the new dll to this common output directory. We use the following command:
XCOPY "$(TargetPath)" "\CommonAssemblies\" /R/Y
Where the macro $(TargetPath) has the fully qualified path to the dll that you just built. At this point, we do check in the assemblies from our CommonAssemblies folder.
One final thought, while we classify this as a bug, apparently MS does not and they do not have plans to fix this. The reason we were given was because there are workaround for the problem, and the issue results from not implementing VSS best practices.