Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

.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

Đang mở
  • Có gì không ổn?
#156 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
45/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
csharp
Lĩnh vực
build-system, devtools

Hướng nghiên cứu

Tái hiện vòng lặp với Repro.slnx, Lib/Lib.csproj và các tệp Shared.projitems được mô tả trong issue. Bắt đầu bằng cách lần theo cách SolutionPersistence 1.0.52 mô hình hóa và tuần tự hóa một lần import project được gắn nhãn Shared, so sánh với cách xử lý SharedMSBuildProjectFiles trong .sln cổ điển. Hoàn tất khi solution không còn được mở lại ở trạng thái dirty và đầu ra sau khi lưu vẫn đúng mà không xuất hiện các prompt lặp lại.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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)' &lt; '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 .slnx byte-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 explicit Ids, and self-closing intermediate folders all open clean; the only trigger found is a project importing a .projitems. Removing only the Label="Shared" import line from an otherwise-identical project makes the solution open clean.
  • For contrast, classic .sln persists 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.

Ngôn ngữ chính
C#
Star
213
Fork
14
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của microsoft/vs-solutionpersistence

Tất cả issue của microsoft/vs-solutionpersistence

Issue tương tự

Thêm issue về C#

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.