.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
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 45/100
- Issue 类型
- 缺陷
- 描述清晰度
- 基本清楚
- 活跃度
- 冷清
- 技术栈
- csharp
- 领域
- build-system, devtools
调研方向
使用 issue 中描述的 Repro.slnx、Lib/Lib.csproj 和 Shared.projitems 文件复现该循环。首先跟踪 SolutionPersistence 1.0.52 如何对标记为 Shared 的项目导入进行建模和序列化，并将其与经典 .sln 中对 SharedMSBuildProjectFiles 的处理进行比较。完成标准是 solution 不再以 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 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
microsoft/vs-solutionpersistence 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 68/100
microsoft/vs-solutionpersistence#73 · 2 条评论 ·
-
难度 3/5 1-2 天 新手友好度 72/100
-
难度 5/5 一周以上 新手友好度 30/100
-
Name validation is stricter than VS and MSBuild可能重新可做 @richardstanton 于 127 天前认领，目前没有进行中的 PR。 未关闭
microsoft/vs-solutionpersistence#151 · 已指派 1 人 ·
-
难度 3/5 1-2 天 新手友好度 55/100
microsoft/vs-solutionpersistence#147 · 4 个 reaction ·
查看 microsoft/vs-solutionpersistence 的全部 Issue
相似的 Issue
-
type/automation type/tech-debt
难度 1/5 1 小时以内 新手友好度 72/100
维护者通常 1 天内回复
-
no-stack-trace
难度 2/5 1-3 小时 新手友好度 83/100
维护者通常 1 天内回复
-
enhancement
难度 2/5 1-3 小时 新手友好度 65/100
维护者通常 1 天内回复
-
docs/external squad/utforming
难度 2/5 1-3 小时 新手友好度 75/100
Altinn/altinn-studio#21041 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 68/100
stryker-mutator/stryker-net#3892 ·
维护者通常 1 天内回复