2

我正在向我们项目的主要 git 存储库中的许多解决方案添加一个测试项目。

在此过程中,我注意到向 .sln 文件添加“解决方案文件夹”会修改解决方案中的许多项目。我想不出任何合乎逻辑的理由。在我添加测试项目之前,我只是在谈论添加解决方案文件。

解决方案中的所有项目都是 C# 项目,如果这会有所不同的话。

有谁知道为什么会这样。这是预期的行为,还是错误?另外,有什么方法可以防止这种情况发生吗?

下面的两张图片突出了我正在谈论的行为:

添加新的解决方案文件夹之前

添加解决方案文件夹之前。 没有项目变更。

添加新的解决方案文件夹后

添加解决方案文件夹后。 项目文件已更改。

据我所知,这些变化毫无意义

项目文件的更改是没有意义的。

4

1 回答 1

3

这有点奇怪,但是当人们有多种解决方案并将外壳固定在一个解决方案中而不是另一个解决方案中时,就会发生这些事情。当项目文件被重新渲染时(因为一个项目被添加,重命名,解决方案项目改变等),然后它会选择更正的大小写。如果解决方案文件具有“正确”的大小写,则不会发生任何变化,但如果解决方案文件不匹配,则可能会导致这种级联。

在一种解决方案中固定外壳可能会在另一种解决方案中触发相反的行为。因此,必须立即在所有解决方案文件中修复此问题。如果您有多个分支,请小心。

解决此问题的最佳方法是一次性解决文件系统、项目文件和解决方案文件上的大小写问题。使用文本编辑器执行此操作通常比通过 Visual Studio 项目系统更容易。正则表达式搜索和替换可以在这里创造奇迹。确保一次修复所有这些:

  • (所有)解决方案文件的内容
  • .*proj导致问题的文件
  • 文件系统路径(您可能必须先更改多于大小写才能进行大小写更改)。还要确保您的版本控制系统将接受更改。
  • .*proj其他文件中的项目引用

当单个项目的大小写固定时,更改可能会级联到引用有问题的项目的其他项目文件。项目文件中的ProjectReference元素具有问题项目的相对文件系统路径,并且还捕获其名称。您可以在发布的屏幕截图中清楚地看到这一点:

在此处输入图像描述

于 2019-06-10T18:21:49.167 回答