为什么在Visual Studio中添加解决方案文件夹会更改项目文件，并且有什么方法可以防止这种情况发生？

Question

I am adding a test project to many solutions in our project's primary git repository.

In the process, I noticed that adding a "Solution Folder" to the .sln file modifies many of the projects in the solution. I can think of no logical reason this would be the case. I am only talking about adding the solution file, before I add the test project.

All of the projects in the solution are C# projects, if that would make any difference.

Does anybody know why this is the case. Is this intended behavior, or a bug? Also, is there any way to prevent this from happening?

The two images below highlight the behavior I am talking about:

Before adding the new solution folder :

After adding the new solution folder :

As far as I can tell, the changes are meaningless :

Answer 1

It's a bit weird, but these things happen when people have multiple solutions and fix the casing in one Solution, but not the other. When the project file is re-rendered (because a project is added, renamed, solution item changed etc), then it will pick up the corrected casing. If the solution file has the 'correct' casing, nothing may change, but if the solution file mismatches it can cause this cascade.

Fixing the casing in one solution may trigger the reverse behavior in another solution. Hence, this must be fixed in all solution files at once. Be careful if you have multiple branches.

The best way to fix this is to fix the casing issues on the file system, project files and solution files in a single go. Doing it with a text editor is usually easier than through the Visual Studio project system. Regex search&replace can do wonders here. Make sure you fix all of these at once:

• The contents of (all of) the solution file(s)
• The .*proj file causing the problem
• The file system path (you may have to change more than the case first for the case change to take). Also make sure your Version Control system will take the change.
• The project references in other .*proj files

When the casing of a single project is fixed, the change may cascade to other project files that reference the problematic project. The ProjectReference element in the project file has a relative file system path to the problematic project and also captures its name. You can see this clearly in the screenshot you posted: