ProjectGuids in Project Reference

Why is it that it's always the little details that take the most time in any project / implementation? In my recent efforts to get Team Build up and running, I ran into some of the oddest things. The one that had me pulling what's left of my hair out was a very small thing - the .

Normally, in the course of developing a .NET project, you can pretty much ignore the little details like what the projectGuid is for a given project. The problem that I ran into is that one of the project references had an oudated value.

This is the little beasty that was causing all of the issues (this is in the raw xml of the .vbproj file):

<projectReference include="..\MyClassLibrary.vbproj">&
<name>MyClassLibrary</name>
<project>{D5D5C0F8-6BEB-4415-9CA0-E2A84B8D32B6}
<package>{F184B08F-C81C-45F6-A57F-5ABD9991F28F}</package>
</projectReference>

It's rare that a projectGuid will ever change. In this case, we had to make the MyClassLibrary a VSTO plug in for word. I didn't do the conversion (and wouldn't have caught something like the projectGuid changing if I did), but for some bizarre reason we ended up with a new projectGuid for MyClassLibrary.

This is the little bugger that changed in the MyClassLibrary.vbproj file:

{D5D5C0F8-6BEB-4415-9CA0-E2A84B8D32B6}

The fix was simple, all I had to do was copy the correct Guid to the tag of the other project and I was good to go. Finding that was absolutely horrible though.

Along the path, I found out that the solution would actually build after a complete rebuild. Apparently there is some voodoo happening with the ResolveAssemblyReference.cache files. I'm guessing that these "fix up" the references without changing anything in the original .vbproj files. We didn't notice it in our local build environment because these files were already generated with the correct overriding information. However, the build machine always grabs the source to a clean directory, so these files haven't been generated yet.