Does renaming a project in VS require me to change ALL occurrences of it's old name in the .sln file?

Question

I searched already on stackoverflow and on the internet but I couldn't find a similar specific question.

When i have to rename a already checked-in (tfs) project in my visual studio (2010-2013) solution, I always use a procedure similar to this one here in the accepted question:

stackoverflow.com/questions/2043618/proper-way-to-rename-solution-and-directories-in-visual-studio

Here is the important snippet from there (thanks to author):

1. Close Visual Studio.
2. Create a backup of your .sln file (you can always roll back).
3. Imagine you want to rename directory "Project1" to "Project2".
4. If not using source control, rename the folder from "Project1" to "Project2" using Windows Explorer.
5. If using source control, rename the folder from "Project1" to "Project2" using the functions supplied by source control. This preserves the history of the file. For example, with TortoiseSVN, right click on the file, select TortoiseSVN .. Rename.
6. In the .sln file, edit all instances of "Project1" to be "Project2".
7. Restart Visual Studio, and everything will work as before, but with the project in a different directory.

..and there i always do step 6:

Step 6.: In the .sln file, edit all instances of "Project1" to be "Project2".

By observing the .sln file i could see that until step 6 (so in my case of using the tfs i did steps 1,2,3 and 5) there are still occurrences of the old project name in the .sln file:

Project("{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}") = "Project2", "Project1\Project2.csproj", "{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}"

and:

SccProjectUniqueName92 = Project1\Project2.csproj

SccProjectName92 = Project1

SccLocalPath92 = Project1

Until now i had no problems with that approach. But as i could see a colleague of me is skipping step 6 and there are still occurrences of the old project name in the .sln file.

Now i wonder if step 6 is really needed/required? I am keeping using step 6 just for more cleanness! But whats your opinion on this? Could the old project name occurrences in the .sln file (if skipping step 6) even some time lead to functional problems with tfs/vs etc.? Or is it only for the purpose of a cleaner/clearer code better to do carry out step 6?

Answer 1

If you are renaming a project within a solution, that is under source control, really all you need to do is to rename the project in Visual Studio and then submit the changes to the project file and the solution file, back into source control.

Visual Studio and TFS should handle all of the changes for you, VS will rename the project and update the references in the SLN file.

TFS will handle the rename and will maintain the history line.

The only time it should get complicated is if you are moving projects and solutions within source control, when you are carrying out this sort of task then the list above is a fair description of what needs to be done, but after step 4 i would just open the solution remove the project that can no longer be found and add in the newly renamed project, this would then automatically handle the sln file changes. now obviously this would orphan your history on the project if it was under source control, but you would make the project name change through TFS before reopening the solution.

if you want to manually change the sln file then a find and replace operation is the simplest way to update the file.

Coming Back to your question. You really should ensure the sln file is correct as this tells VS where to download the files from and what projects actually make up the solution, by not updating the sln file correctly you, or other users of TFS may not get the correct files downloaded and you may have issues opening your solution.

An example of fall out from not having these files in line can be found in this question Why missing <SccProjectName> in project file cause "The project file is not bound to source control"