VS 2015にアップグレードして以来、私のチームはランダムな風変わりなことを経験してきました。これは現在Microsoftで解決されていると確信しています。かなり厄介なのは、特に分岐した後、プロジェクト参照が失われているように見えることです。私は昨日ソリューションの新しいブランチに取り組み始めましたが、タイプが認識されず、名前空間の使用が不要であると引用されていたことがわかりました(突然認識されなくなったタイプのためのものであるため)。
プロジェクト内の参照には、参照の問題を示すアイコンが表示されませんでしたが、機能するかどうかを確認するために、プロジェクト参照を削除して再度追加しました。これにより、そのタイプがもう一度認識されました。
もちろん、これでプロジェクトファイルが更新されたので、どのような変更が加えられたかを確認しました。参照を検出できなかったプロジェクトと現在検出できたプロジェクトの唯一の違いは、GUIDの英字が小文字から大文字に変更されたことです。例:
古い、壊れた参照:
<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を大文字に変換することなく)修正する方法を探しています。
これらの「壊れた」参照はビルドを壊していないこと、およびビルドエラーではなくIntelliSenseエラーとしてエラーリストにのみ表示されることに注意してください。したがって、参照は実際には壊れていません。IntelliSenseが壊れているだけです(これは間違いなくもっと悪いですか?!)。
TL; DR
Visual Studioは、プロジェクトにGUIDを割り当てる方法またはプロジェクト参照でそれらのGUIDを指定する方法について完全に一貫しているわけではありません。 ProjectGuid
要素を中括弧で囲んだ大文字のGUIDと、Project
要素を中括弧で囲んだ小文字のGUIDを使用することで、問題を解決できました(参照)。
背景
大規模なソリューション(60以上のC#プロジェクト)があり、ビルド順序が正しくないと、まだビルドされていない(ただしビルドされているはずの)参照プロジェクトの解決に失敗するため、ソリューションの再ビルドで定期的に問題が発生していました。ビルドの依存関係とビルドの順序は正しいように見えました。 MSBuildバッチビルドは正常に機能しました。これは、VisualStudioから再構築する場合にのみ問題でした。
すべてのプロジェクトGUIDを中括弧で大文字に、すべてのプロジェクト参照GUIDを中括弧で小文字に強制すると、問題が修正されました。これは通常Visual StudioがこれらのGUIDを生成する方法ですが、常にではありません。
まったく新しいテストソリューションで調査を行ったところ、次のことがわかりました。
参照GUIDをすべて大文字またはすべて小文字に置き換えることで、壊れた再構築を修正できました。これは、Visual Studioの問題(おそらく辞書で大文字と小文字を区別する文字列キー)を引き起こしていた大文字と小文字の組み合わせに関するものです。 Visual Studioは通常、小文字のGUIDを使用して参照を追加するため、これを選択しました。
正規表現の検索と置換
これを修正するために、Notepad ++の正規表現ベースの検索とファイルの置換を使用して、.csprojファイル内のすべてのProjectGuidを中かっこで大文字にしました(コンソールアプリケーションのデフォルトであり、プロジェクト参照をに追加した後にVisualStudioのスタイルが適用されます。事業):
Find what: (<ProjectGuid>)\{?([0-9a-f-]+)\}?(</ProjectGuid>)
Replace with: \1{\U\2}\E\3
Search in: *.csproj
必ず正規表現検索をオンにし、マッチケースをオフにしてください。また、すべてのファイルを検索しないでください。そうしないと、@ AspNycで示されているように、たとえば* .xprojファイルで不要な変更を加える可能性があります。 (大文字と小文字を変更するための正規表現の使用に関する追加情報については、 この回答 を参照してください。)
次に、プロジェクトへのすべての参照を中括弧で小文字に置き換えました(これはVisual Studioが通常行うことです)。
Find what: (<Project>)\{?([0-9a-f-]+)\}?(</Project>)
Replace with: \1{\L\2}\E\3
Search in: *.csproj
これらの変更を行った後、VisualStudioソリューションの再構築が確実に機能するようになりました。 (少なくとも次回まで、不正な大文字の参照GUIDがプロジェクトに侵入します。)
VS2017 v15.7をv15.9に更新するときに、同様の問題が発生しました。
私にとっての答えは、VSを閉じ、ソリューションのルートディレクトリにある非表示の.vs
フォルダーをクリアして、VSを再起動することでした。
プロジェクトシステムにバグがあるようです。このPowerShellはプロジェクトをループし、すべての参照を大文字にします。
#FixGuids
get-childitem -recurse | ?{ @('.sln', '.csproj', '.vbproj') -contains $_.Extension } | %{
[regex]::Replace((gc $_.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
}
それは非常に単純です。参照以外の目的でプロジェクトのガイドに依存している場合は、それをよりインテリジェントなものに変えたいと思うかもしれません。
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ファイルのタイムスタンプを変更することによって無意識のうちに問題を修正していました。これらのタイムスタンプが更新された後、ビルドシステムは非常に満足しているように見え、煩わしい動作を停止しました(すでにビルドされたプロジェクトの再構築を継続的に試みます)。
ギッドのキャラクターケーシングは、結局問題になることはありませんでした。私の知る限り、VS2019は大文字と小文字の両方のガイドで問題ありません。私の実験に基づいて、ソースプロジェクトと一致しない場合もあります(たとえば、元のソースプロジェクトでは大文字を使用でき、参照プロジェクトでは小文字を使用できます)。
誰かに役立つ場合は、パスの下にあるすべてのcsprojファイルの書き込み時間を調整できるPowerShellを以下に示します。これは、msbuildシステムがビジュアルスタジオで誤動作しているときに使用するもう1つのトリックになります。
$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
}
}
}