Ссылки на проекты VS не работают с учетом регистра GUID

TL;DR

Visual Studio не полностью соответствует тому, как она назначает идентификаторы GUID проектам или, как она указывает эти идентификаторы GUID в ссылках на проекты. Мне удалось решить проблему, используя GUID в верхнем регистре с фигурными скобками для элементов ProjectGuid и в нижнем регистре с фигурными скобками для элементов Project (в ссылках).

Фон

У нас есть большое решение (более 60 проектов C#), и у нас были регулярные проблемы с решением Rebuild, поскольку неправильный порядок сборки приводил к сбою в разрешении связанных проектов, которые еще не были собраны (но должны были быть). Зависимости сборки и порядок сборки отображаются правильно. Пакетная сборка MSBuild работала нормально, проблема была только при перестройке из Visual Studio.

Проблема была устранена принудительным переводом всех GUID проекта в верхний регистр с фигурными скобками и всех GUID ссылок проекта в нижний регистр с фигурными скобками. Эти идентификаторы GUID обычно создаются Visual Studio, но не всегда.

Проведя небольшое исследование в совершенно новом тестовом решении, оказалось, что:

1. Генерируемые идентификаторы GUID для проектов консольных приложений указываются в верхнем регистре с фигурными скобками.
2. Сгенерированные идентификаторы GUID для проектов библиотеки классов изначально имеют строчные буквы без фигурных скобок.
3. Если в новую ссылку на проект добавляется проект библиотеки классов с GUID в нижнем регистре, то не только добавляется GUID ссылки, но и GUID проекта преобразуется в верхний регистр с фигурными скобками.
4. Если создается копия проекта библиотеки классов, а затем добавляется в решение, ее идентификатор GUID заменяется новым, в котором используются прописные буквы и фигурные скобки. (Но если сделана копия и ее GUID удален вручную, Visual Studio не вставит новый GUID в файл .csproj.)
5. Ссылки на проекты GUID обычно используют строчные буквы и фигурные скобки, но каким-то образом наш проект накопил кучу ссылок GUID в верхнем регистре.
6. GUID в .sln всегда используют верхний регистр и фигурные скобки.

Я смог исправить нашу неработающую перестройку, заменив ссылочные GUID либо на все прописные, либо на все строчные буквы — что-то в сочетании верхнего и нижнего регистра создавало проблемы Visual Studio (возможно, чувствительные к регистру строковые ключи в словаре где-то?) Поскольку Visual Studio обычно добавляет ссылки с GUID в нижнем регистре, я выбрал именно этот вариант.

Поиск и замена регулярных выражений

Чтобы исправить это, я использовал поиск и замену в файлах на основе регулярных выражений Notepad++, чтобы заставить все ProjectGuids в файлах .csproj быть в верхнем регистре с фигурными скобками (по умолчанию для консольных приложений, и стиль, который Visual Studio будет применять после добавления любой ссылки на проект в проект):

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

Не забудьте включить поиск по регулярному выражению и отключить регистр. И не ищите во всех файлах, иначе вы можете внести ненужные изменения, например, в файлы *.xproj, как отмечает @AspNyc. (Дополнительную информацию об использовании регулярных выражений для изменения регистра см. в этом ответе.)

Затем я заменил все ссылки на проекты фигурными скобками в нижнем регистре (что обычно и делает Visual Studio):

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

После внесения этих изменений перестроение решения Visual Studio теперь работает надежно. (По крайней мере, пока в следующий раз в наш проект не проникнут мошеннические GUID-ссылки в верхнем регистре.)

У меня возникла аналогичная проблема при обновлении VS2017 v15.7 до v15.9.

Ответ для меня состоял в том, чтобы закрыть VS, очистить скрытую папку .vs в корневом каталоге моего решения и перезапустить VS.

Кажется, в системе проектов есть ошибка. Этот powershell будет перебирать проекты и делать все ссылки в верхнем регистре:

#FixGuids

get-childitem -recurse | ?{ @('.sln', '.csproj', '.vbproj') -contains $_.Extension } | %{
   [regex]::Replace((gc -raw $_.FullName), '[{(]?[0-9A-Fa-f]{8}[-]?([0-9A-Fa-f]{4}[-]?){3}[0-9A-Fa-f]{12}[)}]?', { return ([string]$args[0]).ToUpperInvariant() }) |
      Out-File $_.FullName -Encoding "UTF8
}

Это довольно просто. Если вы полагаетесь на руководства в своих проектах для чего-то другого, кроме ссылок, вы можете превратить их во что-то более интеллектуальное.

Чтобы использовать ответ в git-хуке, мне пришлось преобразовать его в синтаксис регулярного выражения sed:

sed -r "s/(<Project>\{?)([0-9A-F-]+)(\}?<\/Project>)/\1\L\2\E\3/g" sample.csproj

Может быть, кто-то найдет это полезным.

Сегодня в Visual Studio 2019 (16.2.2) я столкнулся с проблемами системы сборки, когда проекты без необходимости (и неоднократно) перестраивались всякий раз, когда я начинал сборку своего решения.

(Ни один из обычных шагов не решил проблемы со сборкой, например, удаление папки «.vs» или удаление каталогов «bin» и «obj» и т. д.).

Сначала казалось, что это связано с регистром символов гидов, потому что я смог решить проблему, отредактировав гиды и сохранив проект. Однако это был отвлекающий маневр... Я невольно решил проблему, изменив временные метки всех моих файлов csproj. Система сборки стала намного лучше после того, как эти метки времени были обновлены, и она прекратила раздражающее поведение (постоянные попытки перестроить проекты, которые уже были собраны).

Корпус символов гидов вообще не стал проблемой. Насколько я могу судить, VS 2019 работает как с прописными, так и с строчными буквами. Они могут даже не совпадать с исходным проектом, основываясь на моих экспериментах (например, исходный проект может использовать верхний регистр, а ссылающиеся проекты могут использовать нижний регистр).

Если кому-то это будет полезно, ниже приведен powershell, который позволит вам настроить время записи всех файлов csproj по пути. Это будет еще один трюк, который я использую всякий раз, когда система msbuild плохо себя ведет в Visual Studio.

$datenow = get-date

$files = Get-ChildItem -path "C:\Data\Workspaces\LumberTrack\" -recurse | where { $_.PSIsContainer -eq $false} 

foreach ($file in $files)
{
if ($file.Extension -eq ".csproj") 
{
   Set-ItemProperty $file.FullName LastWriteTime $datenow
   Write-Output $file.FullName
}    
}    
}