Replacing one project in a Visual Studio 2005 solution with another one is not as simple as it sounds. Partially because of Visual Studio playing smart and/or dumb but partially because of project file structures.
Let's say you have made a new branch for one of projects in your solution. It's in a separate folder than the version you're currently using and you want to change all projects in the solution to reference the new one. If you remove the old project from your solution the smartypants Visual Studio will remove references to it from every single project in the solution. Even if you could save only this changed solution and discard changes to project files (don't know if you can), it wouldn't work. Even if you open the solution file in notepad instead, and change it to include the new project, it's a no-go. The solution would probably build fine and the project references in visual studio would seem ok (no exclamation marks, paths shown in the properties window pointing to the new version) but still the wrong dll will be used.
Why is this? The project file (*.csproj) stores its own path to the referenced project and uses it instead of the solution's (this actually makes sense). It doesn't matter if the referenced project is included in the solution or not: Visual Studio will find the referenced project's dlls and use them without building the project. Only if you go to the old project's bin folder and delete everything will you get build errors for projects referencing this old version. And the curios thing is that again if you inspect the culprit project's references, Visual Studio will still insist that it references the new dll's.
So, in the end, you will use compiler errors to detect which projects reference the wrong version, and then remove-add references to change them. You probably would have saved time if you let Visual Studio remove all references in the first place.