Interesting problem in VS 2003 and how to fix it

A team member and I found an interesting problem yesterday that I thought I'd share.  We found the problem by luck, and the fix was weird.  Perhaps there is an easier fix out there.

The problem manifested itself this way:

We needed to build our five different components into different MSI files (don't ask).  Each of the five components refers to one or two "base class" assemblies that are included in each MSI.  Previously, we had a single solution for each component that creates the assembly and then builds the MSI.  Most of the assemblies end up in the GAC.

We were running into problems where we would end up accidentially installing two copies of a base class component into the GAC.

Our solution was to create a single solution file that builds all of the assemblies and builds all of the MSI files.  This way, we could use project references and we'd only get one version of a dependent assembly in any MSI file.

The MSI for installing Assembly A is very similar to the MSI for installing Assembly B, because A and B are very similar.  They both inherit from the same base objects.  The problem was this: After creating the new solution file, and carefully checking every MSI, it appeared that we had it right: MSI-A would install Assembly A, while MSI-B would install Assembly B. 

We saved the project and checked it into version control.  Then ran our build script.  MSI-A would have Assembly A, and MSI-B would have Assembly A as well.  Assembly B was not included in any MSI at all!

Opening the project back up showed that, sure enough, MSI-B was defined to use the project output from project A, even though we specifically told it to use B.  Fixing the reference using Visual Studio didn't help.  The moment we saved and reopened the solution, the MSI would once again show that it refers to the wrong Assembly.

The cause:

When project B was created, the programmer made a copy of all of the files of project A, and put them into another directory.  He changed the names a little and ran with it.  It never occured to him to open up the Project file and change the Project GUID for the new project.

The project GUID is a unique id for each project.  It is stored in the project file, but the solution files and the install projects use them as well.  Since we had two projects in the same solution that used the same GUID, then VS would just pick the first project with that GUID when building the MSIs.  As a result, we had two MSIs with Assembly A and none with Assembly B.

The answer that we went through was to open one of the two project files, in notepad, and change the Project GUID.  Then, go through every solution file that referenced that project file and change the referencing GUID value.  We had to be careful with our solution file that contained both projects, so that we left one project alone and added the other.

This worked.  The effect was odd.  I thought I'd post the problem and our solution in case anyone else makes the mistake of creating an entire project by copying everything from another project, and then putting them both in the same solution file.

Happy coding!