BundleService: MoveDirectory fails with "Access denied" when migrating from legacy layout to versioned layout on Windows

[damianog]

Is there an existing issue for this?

I have searched the existing issues

Describe the bug

When running aspire update --yes --non-interactive (or aspire setup --force) in a project directory on Windows, the CLI fails with:

❌ Bundle extraction failed. Run 'aspire setup --force' to retry, or reinstall the Aspire CLI.

The log shows the bundle extracts successfully into a .tmp.* directory, but the subsequent MoveDirectory to promote it to the final versioned path always fails with System.IO.IOException: Access to the path '...' is denied:

[FAIL] [BundleService] Failed to promote
  C:\Users\<user>\.aspire\versions\13.4.5_<hash>.tmp.<guid>
  to
  C:\Users\<user>\.aspire\versions\13.4.5_<hash>.
System.IO.IOException: Access to the path '...tmp...' is denied.
   at System.IO.FileSystem.MoveDirectory(String, String, Boolean)
   at Aspire.Cli.Bundles.BundleService.<ExtractVersionedLayoutAsync>d__22.MoveNext()

The versions/ directory does not exist beforehand, user permissions are correct (full control), and the issue is not related to antivirus.

Steps To Reproduce

1. Install Aspire CLI (e.g. via aspire update --self --channel stable) on a machine where the bundle was previously extracted in the legacy layout (~/.aspire/managed/ and ~/.aspire/dcp/)
2. Run aspire update --yes --non-interactive in a project directory
3. Observe the BundleService attempting to extract the bundle into ~/.aspire/versions/<version>.tmp.<guid> and then failing on MoveDirectory

Expected Behavior

The bundle should be promoted from the .tmp.* directory to ~/.aspire/versions/<version> successfully, or the CLI should fall back to the existing legacy layout.

Actual Behavior

MoveDirectory throws IOException: Access to the path is denied even though the user has full permissions on ~/.aspire/versions/.

Workaround

Manually create the target versioned directory and copy managed/ and dcp/ from the legacy layout:

$target = "C:\Users\<user>\.aspire\versions\<version-hash>"
New-Item -ItemType Directory -Force "$target\managed" | Out-Null
New-Item -ItemType Directory -Force "$target\dcp" | Out-Null
Copy-Item -Recurse -Force "C:\Users\<user>\.aspire\managed\*" "$target\managed\"
Copy-Item -Recurse -Force "C:\Users\<user>\.aspire\dcp\*" "$target\dcp\"

Also, updating .aspire-bundle-version to match the CLI version avoids the repeated re-extraction attempts:

Set-Content "C:\Users\<user>\.aspire\.aspire-bundle-version" "13.4.5+<hash>|<id>|<timestamp>"

Environment

• OS: Windows 11
• Aspire CLI version: 13.4.5+73114e86c64aeb9f3f3c7da8e37df1ae4281b27e
• Shell: PowerShell
• Layout at time of failure: legacy (managed/ + dcp/ directly under ~/.aspire, no versions/ directory)

Additional Context

The issue appears to be specific to the transition from the legacy layout (where managed/ and dcp/ live directly under ~/.aspire) to the new versioned layout (~/.aspire/versions/<hash>/). The MoveDirectory call fails in this scenario on Windows despite correct permissions. The --non-interactive flag also reveals a secondary bug: without it, aspire update --self fails with Cannot show selection prompt since the current terminal isn't interactive, which means the flag is either undocumented or not consistently honored.

[joperezr]

🤖 Aspire triage pass — 2026-06-17 14:45 UTC

Area: area-cli (Aspire.Cli/Bundles/BundleService)
Kind: regression
Repro: yes-minimal — see the Steps To Reproduce and Actual Behavior sections of the issue body, plus the stack trace in the issue body
Affected version(s): 13.4.5+ on Windows (versioned-layout transition); machines with the legacy ~/.aspire/managed + ~/.aspire/dcp layout. Auto-created versioned-only installs likely unaffected.
Severity: S2 — aspire update fails for Windows users migrating from the legacy layout; manual Copy-Item workaround exists but is non-obvious and most users will hit it. Secondary issue called out: --non-interactive not consistently honored by aspire update --self.

Urgency: 🟡 vNext — recommend milestone 13.5
Reason: Affects the legacy → versioned-layout migration path introduced by the recent bundle-versioning work (#16408, #17282, #17505). Likely a regression in the new versioned-layout code path on Windows, but I cannot confidently pin the regression baseline to a specific prior 13.x release where this same migration succeeded — versioned layout itself is recent. Per workflow rules, unclear baseline + existing workaround → 13.5, not 13.4.x. A human should re-evaluate for 13.4.x if confirmed as a clean regression vs. a prior 13.x.

Suggested owner(s): @danegsta (score 9), backup @radical (score 4)
Evidence:

• danegsta merged the versioned-layout system: Add symlink/junction support for bundle installs with versioned directories #16408 (symlink/junction support for bundle installs with versioned directories), Protect CLI bundle versions with leases #17282 (leases protecting CLI bundle versions), Default CLI bundle extraction to Aspire home for sidecar-less installs #17505 (default CLI bundle extraction to Aspire home for sidecar-less installs) — directly the code path failing here
• radical merged adjacent CLI bundle work: feat(cli): co-locate bundle with CLI binary for packager-managed installs #16817 (co-locate bundle with CLI binary), feat(cli): aspire doctor lists every Aspire CLI install on the machine #17105, Add WinGet/Homebrew installer dogfood flows for PR builds #17115
• JamesNK is the highest-volume area-cli contributor (36 merged PRs/90d) but no specific BundleService touches surfaced

Confidence: medium
Needs human?: yes — regression baseline unclear (cannot confirm legacy→versioned migration succeeded on a specific prior 13.x); also recommend confirming whether the secondary --non-interactive flag bug should be split into its own issue.

Dry-run mode — no labels or milestone applied. Reply /triage apply to promote, or edit and reapply.

[davidfowl]

@danegsta can you take a look?

[danegsta]

@damianog what terminal are you running aspire update --yes in? You shouldn't need to specify --non-interactive and "Cannot show selection prompt since the current terminal isn't interactive" would seem to indicate you aren't running in a standard terminal environment.

Can you run aspire doctor and share the output to see if it flags anything problematic?

There's nothing in the bundle logic that would interact with the old layout directly (they're intentionally separate layouts precisely to avoid conflicts during update). The most likely scenario is that something is holding a temporary file handle on one or more of the assemblies in the temp folder we unpack the bundle into so that the directory move fails. If not a virus scanner, it could also be an indexing scan of some sort.

Would you be willing to run Procmon while reproducing the issue to capture if a separate process is involved or not? It'll capture all handle events while running and would reveal if another process executed a CreateFile operation on one of the files in the bundle folder just before our move command failed.

Quickest way to setup a capture would be to run something like the following PowerShell script. It'll capture everything that happens between starting capture and terminating the capture (so not just Aspire operations) so DO NOT upload it:

# Start capture in the background, writing to a native PML log.
# /Quiet  - no UI
# /Minimized - no window
# /BackingFile - where to write the capture
# /AcceptEula - skip the EULA prompt
Procmon64.exe /AcceptEula /Quiet /Minimized /BackingFile .\aspire-bundle.pml

# Reproduce the failure
aspire update --yes --non-interactive

# Stop capture
Procmon64.exe /Terminate

You'd then need to analyze the resulting .pml file in the Procmon GUI to identify the candidate for the locked file:

Analysis

Open the resulting .pml in Procmon GUI. The key columns are Time of Day, Process Name, Operation, Path, Result, Detail.

What to look for, in order:

1. Filter → Result is ACCESS DENIED and Path contains .aspire\versions. The denied SetRenameInformationFile operation from aspire.exe (or dotnet.exe) is the failure. Note its timestamp.
2. Remove the Result filter (but keep the Path filter), find that same path moments earlier (typically <500ms before). Look for CreateFile operations from another process on files inside the .tmp. directory — that's your culprit. Common process names: MsMpEng.exe (Defender), SearchProtocolHost.exe / SearchFilterHost.exe (indexer), CSFalconService.exe (CrowdStrike), SentinelAgent.exe, xagt.exe (FireEye), ccSvcHst.exe (Symantec).
3. Right-click the suspect CreateFile → Properties → Event tab shows the share mode. Absence of Delete in the share mode is what causes the subsequent rename to fail.

If an external application is causing the issue that should reveal it. If not we'll need to figure out other possible causes.

[damianog]

Hi @danegsta

I reproduced the error by:

Open Terminal App with PowerShell 7.6.2 in user mode

dotnet tool uninstall aspire.cli -g

deleting the eventually remained folder C:\Users\<user>\.aspire

I installed the old aspire cli 13.2.4

dotnet tool install aspire.cli -g --version 13.2.4

than updated to te lastest stable, actually 13.4.5

aspire update --self

Now inside my folder project if I run:

aspire update

give the error: Bundle extraction failed. Run 'aspire setup --force' to retry, or reinstall the Aspire CLI

cli_20260618T095222_b57df41e.log

`aspire setup --force' instead give: Bundle was extracted to C:\Users\damiano\.dotnet but layout validation failed

cli_20260618T095807_24cac32f.log

If I start procmon64, UAC opens and I give OK, but in this case aspire update runs without error.
I need more investigation.