在 VS 中重命名项目是否需要我更改 .sln 文件中所有出现的旧名称？

Question

我已经在 stackoverflow 和互联网上进行了搜索，但找不到类似的具体问题。

当我必须在我的 Visual Studio (2010-2013) 解决方案中重命名已签入 (tfs) 项目时，我总是在已接受的问题中使用与此类似的过程：

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

这是重要的sn-p（感谢作者）：

1. 关闭 Visual Studio。
2. 创建 .sln 文件的备份（您可以随时回滚）。
3. 假设您要将目录“Project1”重命名为“Project2”。
4. 如果不使用源代码管理，请使用 Windows 资源管理器将文件夹从“Project1”重命名为“Project2”。
5. 如果使用源代码管理，请使用源代码管理提供的功能将文件夹从“Project1”重命名为“Project2”。这 保留文件的历史记录。例如，使用 TortoiseSVN， 右键单击文件，选择 TortoiseSVN .. 重命名。
6. 在 .sln 文件中，将“Project1”的所有实例编辑为“Project2”。
7. 重新启动 Visual Studio，一切都会像以前一样工作，但项目位于不同的目录中。

..我总是在那里做第 6 步：

第 6 步：在 .sln 文件中，将“Project1”的所有实例编辑为“Project2”。

通过观察 .sln 文件，我可以看到直到第 6 步（所以在我使用 tfs 的情况下，我执行了第 1、2、3 和 5 步）在 .sln 文件中仍然出现旧项目名称：

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

和：

SccProjectUniqueName92 = Project1\Project2.csproj

SccProjectName92 = 项目1

SccLocalPath92 = Project1

到目前为止，我对这种方法没有任何问题。但正如我所见，我的一位同事正在跳过第 6 步，并且 .sln 文件中仍然出现旧项目名称。

现在我想知道第 6 步是否真的需要/需要？ 我继续使用第 6 步只是为了更清洁！但您对此有何看法？ .sln 文件中出现的旧项目名称（如果跳过第 6 步）是否会在某些时候导致 tfs/vs 等的功能问题？ 还是只是为了更清晰/更清晰的代码更好地执行第 6 步？

Answer 1

如果您在解决方案中重命名项目，即在源代码控制下，您真正​​需要做的就是在 Visual Studio 中重命名项目，然后将更改提交到项目文件和解决方案文件，返回源代码控制。

Visual Studio 和 TFS 应为您处理所有更改，VS 将重命名项目并更新 SLN 文件中的引用。

TFS 将处理重命名并维护历史行。

唯一会变得复杂的情况是，如果您在源代码控制中移动项目和解决方案，当您执行此类任务时，上面的列表是对需要做什么的公平描述，但在第 4 步之后我只需打开解决方案，删除无法再找到的项目并添加到新重命名的项目中，这将自动处理 sln 文件更改。现在显然，如果项目处于源代码控制之下，这将孤立您的项目历史记录，但您可以在重新打开解决方案之前通过 TFS 更改项目名称。

如果您想手动更改 sln 文件，那么查找和替换操作是更新文件的最简单方法。

回到你的问题。 你真的应该确保 sln 文件是正确的，因为这会告诉 VS 从哪里下载文件以及哪些项目实际上构成了解决方案，因为你没有正确更新 sln 文件，或者 TFS 的其他用户可能无法下载正确的文件并且您可能在打开解决方案时遇到问题。

可以在此问题Why missing <SccProjectName> in project file cause "The project file is not bound to source control" 中找到因没有这些文件而导致的失败示例