VS 项目引用因 GUID 区分大小写而中断 [英] VS Project References Broken On Case Sensitivity of GUID

问题描述

自从升级到 VS 2015 以来，我的团队遇到了一些随机的古怪事情，我确信 Microsoft 现在正在解决这些问题.一个非常烦人的问题是我们似乎丢失了项目引用，尤其是在分支之后.昨天我开始研究我们解决方案的一个新分支，结果发现类型无法识别并且命名空间 using 被认为是不必要的(因为它们用于突然变得无法识别的类型).

Since upgrading to VS 2015, my team has experienced random quirky things which I'm sure are being worked out at Microsoft right now. One pretty annoying one is that we seem to lose project references, especially after branching. I began to work on a new branch of our solution yesterday only to find out that types were unrecognized and namespace usings were being cited as unnecessary (because they were for the types that had suddenly become unrecognized).

项目中的引用没有显示任何表示引用有问题的图标，但只是为了看看它是否有效，我删除并重新添加了一个项目引用，这导致其类型再次被识别.

The references in the project did not show any icons indicating a problem with the reference, but just to see if it would work, I removed and re-added a project reference, which caused its types to be recognized once more.

当然，这更新了项目文件，所以我查看了进行了哪些更改.无法检测到引用的项目与现在可以检测到的项目之间的唯一区别是 GUID 中的字母字符已从小写更改为大写.例如:

This, of course, updated the project file, so I looked to see what changes had been made. The only difference between the project that could not detect the reference and the one that now can is that the alpha characters in the GUID had been changed from lower case to upper case. For example:

旧的、损坏的参考:

<ProjectReference Include="path/redacted">
    <Project>{95d34b2e-2ceb-499e-ab9e-b644b0af710d}</Project>
    <Name>Project.Name.Redacted</Name>
</ProjectReference>

新的、固定的参考:

<ProjectReference Include="path/redacted">
    <Project>{95D34B2E-2CEB-499E-AB9E-B644B0AF710D}</Project>
    <Name>Project.Name.Redacted</Name>
</ProjectReference>

我正在寻找发生这种情况的原因以及如何修复它，而无需手动删除和重新添加所有位置的引用(并且无需将所有项目文件 GUID 转换为大写).

I'm looking for the reason this is happening and how I might fix it without having to manually remove and re-add references all over the place (and without having to convert all the project file GUIDs to upper case).

我应该注意，这些损坏的"引用不会破坏构建，它们仅在错误列表中显示为 IntelliSense 错误，而不是构建错误.因此，引用并没有真正损坏，它们只是损坏了 IntelliSense(可以说更糟?！).

I should note that these "broken" references are not breaking the build, and that they only show up in the Error List as IntelliSense error, not build errors. So, the references aren't really broken, they've just broken IntelliSense (which is arguably worse?!).

推荐答案

TL;DR

Visual Studio 关于如何将 GUID 分配给项目或在项目引用中指定这些 GUID 的方式并不完全一致.我能够通过对 ProjectGuid 元素使用带大括号的大写 GUID 和对 Project 元素使用带大括号的小写 GUID(在参考文献中)来解决这个问题.

Visual Studio isn't entirely consistent about how it assigns GUIDs to projects or how it specifies those GUIDs in project references. I was able to resolve the problem by using upper case GUIDs with braces for ProjectGuid elements and lower case with braces for Project elements (in references).

背景

我们有一个大型解决方案(60 多个 C# 项目)，并且解决方案 Rebuild 经常遇到问题，因为错误的构建顺序会导致无法解析尚未构建(但应该构建)的引用项目.构建依赖项和构建顺序似乎是正确的.MSBuild 批量构建工作正常，只是从 Visual Studio 重建时出现问题.

We have a large solution (60+ C# projects), and were having regular issues with solution Rebuild as incorrect build order would cause failure to resolve referenced projects that had not yet been built (but should have been). Build Dependencies and Build Order appeared correct. MSBuild batch build worked fine, it was only a problem when rebuilding from Visual Studio.

将所有项目 GUID 强制为大写并带大括号，将所有项目引用 GUID 强制为小写并带大括号解决了该问题.这是通常 Visual Studio 生成这些 GUID 的方式，但并非总是如此.

Forcing all project GUIDs to upper case with braces and all project reference GUIDs to lower case with braces fixed the problem. This is usually how Visual Studio generates these GUIDs, but not always.

在一个全新的测试解决方案中做一些调查，结果是:

Doing some investigation in a brand new test solution, it turns out that:

1. 为控制台应用程序项目生成的 GUID 是带大括号的大写.
2. 为类库项目生成的 GUID 最初是小写的，没有大括号.
3. 如果一个新的项目引用被添加到一个带有小写 GUID 的类库项目中，那么不仅引用 GUID 被添加，而且项目 GUID 被转换为带大括号的大写.
4. 如果创建了类库项目的副本，然后将其添加到解决方案中，则其 GUID 将替换为使用大写和大括号的新 GUID.(但如果创建副本并手动删除其 GUID，Visual Studio 不会将替换 GUID 插入 .csproj 文件.)
5. 项目引用 GUID 通常使用小写和大括号，但不知何故我们的项目积累了一堆大写 GUID 引用.
6. .sln 中的 GUID 始终使用大写和大括号.

通过将参考 GUID 替换为全部大写或全部小写，我能够修复损坏的重建——这是关于大写和小写的混合导致 Visual Studio 出现问题(可能是区分大小写的字符串键)在某处的字典中?)由于 Visual Studio 通常添加带有小写 GUID 的引用，这是我选择的选项.

I was able to fix our broken rebuild by replacing the reference GUIDs with either all upper case or all lower case -- it's something about the mix of upper and lower case that was giving Visual Studio problems (perhaps case-sensitive string keys in a dictionary somewhere?) Since Visual Studio normally adds references with lower case GUIDs, that is the option I chose to go with.

正则表达式搜索 &替换

为了解决这个问题，我使用了基于 Notepad++ 正则表达式的搜索和替换文件，以强制 .csproj 文件中的所有 ProjectGuid 都使用大括号大写(控制台应用程序的默认设置，并且在添加任何项目后将应用样式 Visual Studio项目参考):

To fix this, I used Notepad++ regex-based search and replace in files to force all ProjectGuids in .csproj files to be upper case with braces (the default for console applications, and the style Visual Studio will apply after adding any project reference to the project):

Find what: (<ProjectGuid>){?([0-9a-f-]+)}?(</ProjectGuid>)
Replace with: 1{U2}E3
Search in: *.csproj

一定要开启正则表达式搜索，关闭大小写匹配.并且不要搜索所有文件，否则您可能会进行不想要的更改，例如在 *.xproj 文件中，如@AspNyc 所述.(有关使用正则表达式更改大小写的更多信息，请参阅此答案.)

Be sure to turn on regular expression search, and turn off match case. And don't search all files, or you may make changes you don't want, for example in *.xproj files, as noted by @AspNyc. (See this answer for additional info on use of regular expressions for changing case.)

然后我用大括号替换了对项目的所有引用以使用小写(这是 Visual Studio 通常所做的):

I then replaced all references to projects to use lower case with braces (which is what Visual Studio usually does):

Find what: (<Project>){?([0-9a-f-]+)}?(</Project>)
Replace with: 1{L2}E3
Search in: *.csproj

进行这些更改后，Visual Studio 解决方案重建现在可以可靠地运行.(至少在下一次流氓大写引用 GUID 潜入我们的项目之前.)

Having made these changes, Visual Studio solution rebuild now works reliably. (At least until next time rogue upper case reference GUIDs sneak into our project.)

这篇关于VS 项目引用因 GUID 区分大小写而中断的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！