Init command fixes: prevent csproj package version overwrites, prompt for package installs, add props to csproj required for packaging

[zateutsch]

fixes #395

Prevents --use-defaults flag from overwriting the existing dependency versions in a csproj.

fixes #399

Now prompts users to install nuget packages, unless --use-defaults is specified

fixes #401

If a user opts in to installing the nuget package, init will now make sure that the proper properties are added/removed in the csproj to enable running packaged.

[Copilot]

Pull request overview

Updates winapp init to be more non-destructive for existing .NET project package versions, and adds an opt-in flow for installing the WinApp “dotnet run packaged” integration with associated csproj tweaks.

Changes:

• Prompt user to optionally install Microsoft.Windows.SDK.BuildTools.WinApp and gate packaged-app-related csproj edits behind that choice.
• Preserve existing top-level package versions found in the project (except always updating the WinApp integration package).
• Add csproj helpers to ensure EnableMsixTooling=true, remove WindowsPackageType=None, and annotate PackageReferences with explanatory comments.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 4 comments.

File	Description
src/winapp-CLI/WinApp.Cli/Services/WorkspaceSetupService.cs	Adds WinApp package opt-in prompt; preserves existing package versions; conditionally updates csproj and annotates packages.
src/winapp-CLI/WinApp.Cli/Services/IDotNetService.cs	Extends interface with new csproj-editing helpers.
src/winapp-CLI/WinApp.Cli/Services/DotNetService.cs	Implements csproj regex-based edits for MSIX properties and PackageReference annotations.
src/winapp-CLI/WinApp.Cli.Tests/FakeDotNetService.cs	Updates test fake to delegate new csproj-editing helper methods to the real implementation.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[github-actions]

Build Metrics Report

Binary Sizes

Artifact	Baseline	Current	Delta
CLI (ARM64)	30.50 MB	30.52 MB	📈 +25.5 KB (+0.08%)
CLI (x64)	30.87 MB	30.89 MB	📈 +24.5 KB (+0.08%)
MSIX (ARM64)	12.86 MB	12.89 MB	📈 +24.1 KB (+0.18%)
MSIX (x64)	13.68 MB	13.68 MB	📉 -3.3 KB (-0.02%)
NPM Package	26.77 MB	26.79 MB	📈 +18.6 KB (+0.07%)
NuGet Package	26.85 MB	26.87 MB	📈 +17.9 KB (+0.07%)

Test Results

✅ 722 passed out of 722 tests in 402.7s (+4 tests, -7.3s vs. baseline)

Test Coverage

❌ 20.6% line coverage, 34.6% branch coverage · ✅ +0.2% vs. baseline

CLI Startup Time

41ms median (x64, winapp --version) · ✅ no change vs. baseline

---

Updated 2026-04-15 22:20:43 UTC · commit 3810919 · workflow run

[Copilot]

Just as a heads up, I was blocked by some firewall rules while working on your feedback. Expand below for details.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• https://api.github.com/repos/microsoft/msstore-cli/releases/latest
  • Triggering command: /home/REDACTED/work/winappCli/winappCli/src/winapp-CLI/WinApp.Cli.Tests/bin/Debug/net10.0-windows10.0.19041.0/WinApp.Cli.Tests /home/REDACTED/work/winappCli/winappCli/src/winapp-CLI/WinApp.Cli.Tests/bin/Debug/net10.0-windows10.0.19041.0/WinApp.Cli.Tests --server dotnettestcli --dotnet-test-pipe /tmp/e1e8fd25bf944cffa8fc1338167af312 (http block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated 5 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[zateutsch]

@copilot apply changes based on the comments in this thread

[Copilot]

@copilot apply changes based on the comments in this thread

Applied in commit 5ad4595. RuntimeIdentifierElementRegex now matches the full <RuntimeIdentifier>...</RuntimeIdentifier> element using RegexOptions.IgnoreCase | RegexOptions.Singleline, and insertion uses ridMatch.Index + ridMatch.Length to place the new element directly after the closing tag — safe for both single-line and multi-line elements.

[nmetulev]

After testing, this is what I've found:

• We don't actually need the buildtools package to be installed, we can skip that and remove the code adding the package or checking for it
• The true is not added if the winapp package is not available - it should be added regardless as long as the winappsdk package is in the csproj (whether we add it or not)
• The EnabledMsixTooling doesn't seem to work when the manifest is called appxmanifest.xml, but it works for Package.appxmanifest - we should name the generated manifest Package.appxmanifest to align with the conventions used in winui projects
• We should only add comments in the csproj for things we have changed - if we add the EnableMsixTooling propoerty, we should comment why it was added.

[Copilot]

Pull request overview

Copilot reviewed 43 out of 43 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (8)

src/winapp-CLI/WinApp.Cli/Services/DotNetService.cs:1

• In the false -> true update path, the replacement logic drops indentation on the <EnableMsixTooling> line (the comment is indented via indent, but the element itself is not). Separately, the insert path double-indents <EnableMsixTooling> because element already includes 4 spaces on the second line and the caller prefixes another \" \". Consider building the replacement/insert text so both the comment and element lines use the same detected indent, and avoid embedding indentation inside element if the caller is also adding indentation. This keeps .csproj formatting stable and makes repeated runs/idempotency easier to reason about.
  src/winapp-CLI/WinApp.Cli/Services/DotNetService.cs:1
• In the false -> true update path, the replacement logic drops indentation on the <EnableMsixTooling> line (the comment is indented via indent, but the element itself is not). Separately, the insert path double-indents <EnableMsixTooling> because element already includes 4 spaces on the second line and the caller prefixes another \" \". Consider building the replacement/insert text so both the comment and element lines use the same detected indent, and avoid embedding indentation inside element if the caller is also adding indentation. This keeps .csproj formatting stable and makes repeated runs/idempotency easier to reason about.
  src/winapp-CLI/WinApp.Cli/Services/DotNetService.cs:1
• In the false -> true update path, the replacement logic drops indentation on the <EnableMsixTooling> line (the comment is indented via indent, but the element itself is not). Separately, the insert path double-indents <EnableMsixTooling> because element already includes 4 spaces on the second line and the caller prefixes another \" \". Consider building the replacement/insert text so both the comment and element lines use the same detected indent, and avoid embedding indentation inside element if the caller is also adding indentation. This keeps .csproj formatting stable and makes repeated runs/idempotency easier to reason about.
  src/winapp-npm/package.json:1
• This PR changes the npm package version from 1.0.0 to a prerelease build string and also rewrites the JSON formatting (extra spacing/indentation). Neither is mentioned in the PR description, and the formatting change makes future diffs noisier. If the version bump is intentional, it should align with the repo’s release/versioning policy (and ideally be called out in the PR description); otherwise, consider reverting to the expected semver version and restoring conventional package.json formatting.
  src/winapp-npm/package.json:1
• This PR changes the npm package version from 1.0.0 to a prerelease build string and also rewrites the JSON formatting (extra spacing/indentation). Neither is mentioned in the PR description, and the formatting change makes future diffs noisier. If the version bump is intentional, it should align with the repo’s release/versioning policy (and ideally be called out in the PR description); otherwise, consider reverting to the expected semver version and restoring conventional package.json formatting.
  src/winapp-CLI/WinApp.Cli/Services/DotNetService.cs:1
• New .csproj mutation behaviors were added (EnableMsixTooling insertion/update, WindowsPackageType removal, PackageReference comment annotation), but there are no direct unit tests validating their exact modifications and idempotency. Since this repo already has comprehensive DotNetServiceTests, please add targeted tests that assert: (1) EnsureEnableMsixToolingAsync inserts the property in the intended location and updates false to true without mangling indentation, (2) RemoveWindowsPackageTypeNoneAsync removes the element and doesn’t remove other WindowsPackageType values, and (3) AnnotatePackageReferencesAsync adds comments only once and respects existing comments.
  src/winapp-CLI/WinApp.Cli/Services/DotNetService.cs:1
• New .csproj mutation behaviors were added (EnableMsixTooling insertion/update, WindowsPackageType removal, PackageReference comment annotation), but there are no direct unit tests validating their exact modifications and idempotency. Since this repo already has comprehensive DotNetServiceTests, please add targeted tests that assert: (1) EnsureEnableMsixToolingAsync inserts the property in the intended location and updates false to true without mangling indentation, (2) RemoveWindowsPackageTypeNoneAsync removes the element and doesn’t remove other WindowsPackageType values, and (3) AnnotatePackageReferencesAsync adds comments only once and respects existing comments.
  src/winapp-CLI/WinApp.Cli/Services/DotNetService.cs:1
• New .csproj mutation behaviors were added (EnableMsixTooling insertion/update, WindowsPackageType removal, PackageReference comment annotation), but there are no direct unit tests validating their exact modifications and idempotency. Since this repo already has comprehensive DotNetServiceTests, please add targeted tests that assert: (1) EnsureEnableMsixToolingAsync inserts the property in the intended location and updates false to true without mangling indentation, (2) RemoveWindowsPackageTypeNoneAsync removes the element and doesn’t remove other WindowsPackageType values, and (3) AnnotatePackageReferencesAsync adds comments only once and respects existing comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.