.slnx solution containing a project that imports a .projitems is always dirty in VS — save writes a byte-identical file, prompt returns on every open
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 45/100
- issue の種類
- バグ
- 明瞭さ
- おおむね明確
- 活発さ
- 静か
- 技術スタック
- csharp
- 領域
- build-system, devtools
調査の方向性
issue に記載されている Repro.slnx、Lib/Lib.csproj、および Shared.projitems ファイルを使ってループを再現します。まず、SolutionPersistence 1.0.52 が Shared というラベルのプロジェクト インポートをどのようにモデル化してシリアライズするかを追跡し、従来の .sln における SharedMSBuildProjectFiles の処理と比較します。完了条件は、ソリューションが dirty のまま再び開かれず、繰り返しプロンプトを表示することなく保存出力が正しいままであることです。
索引モデルが issue の本文から書いたものです。
説明
Summary
A .slnx solution containing a project that imports a shared-items file (<Import Project="…\X.projitems" Label="Shared" />) is marked dirty by Visual Studio on every open. Saving — including File → Save Solution As — writes a byte-identical file (SHA-256 verified), and the save prompt returns on the next open, indefinitely.
This is consistent with VS's shared-items bookkeeping (persisted in classic .sln as GlobalSection(SharedMSBuildProjectFiles)) having no representation in the .slnx format: the in-memory model always differs from the parsed file, while the serializer has nothing to write for the difference. The .shproj itself need not be in the solution — an importing project alone triggers it.
Versions
- Visual Studio 2022 Community 17.14.37502.11
- Microsoft.VisualStudio.SolutionPersistence 1.0.52 (NuGet latest, and the identical copy VS ships in
PrivateAssemblies, FileVersion 1.0.52.6595)
Minimal repro (4 files)
Repro.slnx
<Solution>
<Project Path="Lib/Lib.csproj" />
</Solution>
Lib/Lib.csproj
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
</PropertyGroup>
<Import Project="..\Shared\Shared.projitems" Label="Shared" />
</Project>
Shared/Shared.projitems and Shared/SharedClass.cs (full contents)
Shared/Shared.projitems
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<MSBuildAllProjects Condition="'$(MSBuildVersion)' == '' Or '$(MSBuildVersion)' < '16.0'">$(MSBuildAllProjects);$(MSBuildThisFileFullPath)</MSBuildAllProjects>
<HasSharedItems>true</HasSharedItems>
<SharedGUID>a1b2c3d4-0000-4000-8000-000000000001</SharedGUID>
</PropertyGroup>
<PropertyGroup Label="Configuration">
<Import_RootNamespace>Shared</Import_RootNamespace>
</PropertyGroup>
<ItemGroup>
<Compile Include="$(MSBuildThisFileDirectory)SharedClass.cs" />
</ItemGroup>
</Project>
Shared/SharedClass.cs
namespace Shared
{
internal static class SharedClass
{
public static int Answer => 42;
}
}
Steps: open Repro.slnx in VS → let it load → close the solution → VS prompts to save Repro.slnx. Accept: the file is rewritten with identical bytes. Reopen: same prompt. (Confirmed against exactly these files.)
Evidence the on-disk file is already canonical
- A load→save round-trip through SolutionPersistence 1.0.52 reproduces both this file and a 654-project real-world
.slnxbyte-for-byte. - VS Save Solution As on the dirty solution produces a SHA-256-identical file.
- Bisected across ten probe solutions: a
<Configurations>block, solution folders with and without explicitIds, and self-closing intermediate folders all open clean; the only trigger found is a project importing a.projitems. Removing only theLabel="Shared"import line from an otherwise-identical project makes the solution open clean. - For contrast, classic
.slnpersists this bookkeeping (SharedMSBuildProjectFiles), so after one save such a solution reopens clean.
Expected
Either the format/model round-trips shared-items bookkeeping (an element analogous to SharedMSBuildProjectFiles), or VS does not flag the solution dirty for state the serializer will never persist.
Context
Found in ritchiecarroll/go2cs, where both solutions contain two projects importing a shared Symbols project — every open prompts. Happy to provide more detail or test candidate fixes.
- 主要言語
- C#
- スター
- 213
- フォーク
- 14
- PR マージ指標
- 30日以内にマージされた PR はありません
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
microsoft/vs-solutionpersistence のほかの issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
microsoft/vs-solutionpersistence#73 · コメント 2 件 ·
-
難易度 3/5 1〜2日 初心者へのやさしさ 72/100
-
難易度 5/5 1週間以上 初心者へのやさしさ 30/100
-
Name validation is stricter than VS and MSBuild再び着手できるかも @richardstanton が 125 日前に担当しましたが、オープン中のプルリクエストはありません。 オープン
microsoft/vs-solutionpersistence#151 · 担当者 1 名 ·
-
難易度 3/5 1〜2日 初心者へのやさしさ 55/100
microsoft/vs-solutionpersistence#147 · リアクション 4 件 ·
microsoft/vs-solutionpersistence の issue をすべて見る
似ている issue
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 80/100
メンテナーはふだん 1 日以内に返信
-
:watch: Not Triaged aspnet-core/svc fundamentals/subsvc Source - Docs.ms
難易度 1/5 1時間未満 初心者へのやさしさ 85/100
dotnet/AspNetCore.Docs#37785 ·
メンテナーはふだん 1 日以内に返信
-
needs-triage
難易度 2/5 1〜3時間 初心者へのやさしさ 66/100
Azure/azure-sdk-tools#17204 ·
メンテナーはふだん 1 日以内に返信
-
Проблема с Dotnet RUオープンarea-tutorials needs-triage
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
dotnet/website-feedback#1779 ·
-
[Bug] SwipeControl in Execute mode with more than one item replaces the whole UI with an error panelオープンbug needs-triage
難易度 2/5 1〜3時間 初心者へのやさしさ 67/100
microsoft/microsoft-ui-reactor#1344 ·
メンテナーはふだん 1 日以内に返信