Serialize concurrent .NET tool operations with file locks

[Copilot]

Concurrent tool operations can race while downloading packages, mutating the global tool store, or creating shared shims. This change serializes those operations with persistent file locks opened using FileShare.None.

Changes

• Use package/version locks for local package extraction and a store-wide lock for global/tool-path install, update, and uninstall operations.
• Keep lock files on disk so stale files are harmless; ownership is represented only by the open exclusive handle.
• Retain package and store locks through ambient transaction completion so rollback cannot delete or restore over a subsequent operation.
• Normalize package identities and lock paths across casing and DOTNET_CLI_HOME differences.
• Make tool install, restore, update, execute, and uninstall paths asynchronous and propagate cancellation through NuGet lookup, download, extraction, and lock waits.
• Preserve --disable-parallel behavior for tool restore and revalidate update --all entries under the store lock.
• Add concurrency, cancellation, rollback, stale-lock, RID-package, shared-shim, and update/uninstall regression coverage.

When contention is detected, the CLI reports that another installation is in progress and waits up to the existing timeout. Users can cancel the wait with Ctrl+C.

Fixes #51831

[Copilot]

Pull Request Overview

This pull request implements concurrent tool installation protection using named mutexes to prevent "file being used by another process" errors when multiple dotnet CLI processes attempt to install the same .NET tool simultaneously.

Key changes:

• Adds named mutex synchronization (tool-install-{packageId}-{packageVersion}) to serialize concurrent installations per package/version combination
• Implements two-stage mutex acquisition with user notification for better UX
• Adds comprehensive test coverage for concurrent installation scenarios

Reviewed Changes

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

File	Description
src/Cli/dotnet/ToolPackage/ToolPackageDownloaderBase.cs	Core implementation: wraps DownloadTool method with named mutex, includes timeout handling and mutex name generation
src/Cli/dotnet/CliStrings.resx	Adds two new error messages: ToolInstallationTimeout and ToolInstallationWaiting for user communication
src/Cli/dotnet/xlf/*.xlf	Adds localization entries for the new error messages across 13 language files (all marked as state="new")
test/Microsoft.DotNet.PackageInstall.Tests/ToolPackageDownloaderTests.cs	Adds GivenConcurrentInstallationsTheyDoNotConflict test with concurrent Task.Run executions; includes minor formatting fixes (alphabetized using statements, whitespace cleanup)

[github-actions]

Due to lack of recent activity, this PR has been labeled as 'Stale'. It will be closed if no further activity occurs within 7 more days. Any new comment will remove the label.

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).
2 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[github-actions]

🔴 Build Failure Analysis — MSTEST0049 errors (all 10 legs)

All 10 build legs fail with MSTEST0049 build errors in two test projects:

• test/dotnet.Tests/dotnet.Tests.csproj — 11 errors
• test/Microsoft.DotNet.PackageInstall.Tests/Microsoft.DotNet.PackageInstall.Tests.csproj — 39 errors

Root Cause

This PR changed IToolPackageDownloader to expose async methods (InstallPackageAsync, GetNuGetVersionAsync, TryGetDownloadedToolAsync) each with a CancellationToken cancellationToken = default parameter, and added sync extension helpers (InstallPackage, GetNuGetVersion) that also expose CancellationToken. The [MSTEST0049]((learn.microsoft.com/redacted) analyzer fires as a build error (because both MSTest.Sdk-based projects treat analyzer warnings as errors) whenever a test calls one of these methods through an Action lambda or directly without passing TestContext.CancellationToken.

Files modified by this PR that have errors

test/dotnet.Tests/CommandTests/Tool/Uninstall/ToolUninstallGlobalOrToolPathCommandTests.cs — 5 errors at lines 51, 87, 194, 234, 259

test/Microsoft.DotNet.PackageInstall.Tests/ToolPackageDownloaderTests.cs — 25 errors at lines 61, 88, 113, 155, 178, 203, 221, 243, 266, 299, 327, 352, 385, 420, 430, 479, 529, 541, 547, 571, 583, 584, 592, 621, 629

Other files with pre-existing errors (NOT modified by this PR, but also failing)

The following test files were last touched by PR #54646 ("Resolve analyzers from the analyzers group in project.assets.json"), which likely activated the MSTEST0049 analyzer. They have pre-existing violations that were already present on the base branch but now become build errors:

• test/dotnet.Tests/CommandTests/Tool/Uninstall/ToolUninstallCommandTests.cs — 4 errors (lines 32, 47, 62, 76)
• test/dotnet.Tests/CommandTests/Tool/Uninstall/ToolUninstallLocalCommandTests.cs — 1 error (line 123)
• test/dotnet.Tests/CommandTests/Tool/Install/ToolInstallGlobalOrToolPathCommandTests.cs — 1 error (line 820)
• test/Microsoft.DotNet.PackageInstall.Tests/NuGetPackageInstallerExtractTests.cs — 2 errors
• test/Microsoft.DotNet.PackageInstall.Tests/NuGetPackageInstallerTests.cs — 3 errors
• test/Microsoft.DotNet.PackageInstall.Tests/ToolPackageInstallerNugetCacheTests.cs — 2 errors
• test/Microsoft.DotNet.PackageInstall.Tests/ToolPackageUninstallerTests.cs — 1 error

Note: If the base branch build is also failing due to those pre-existing violations, this PR cannot land until they are resolved too. In that case, this PR author only needs to fix the violations in files they modified; the pre-existing violations are separate.

Fix

For every call site flagged by MSTEST0049, pass cancellationToken: TestContext.CancellationToken (where the test class has access to TestContext) to the optional cancellationToken parameter of InstallPackage, GetNuGetVersion, etc.

Example pattern — before:

var package = downloader.InstallPackage(
    new PackageLocation(nugetConfig: testDir.WithFile("NuGet.config")),
    packageId: TestPackageId,
    verbosity: TestVerbosity,
    versionRange: VersionRange.Parse(TestPackageVersion),
    targetFramework: _testTargetframework,
    isGlobalTool: true,
    verifySignatures: false);

After:

var package = downloader.InstallPackage(
    new PackageLocation(nugetConfig: testDir.WithFile("NuGet.config")),
    packageId: TestPackageId,
    verbosity: TestVerbosity,
    versionRange: VersionRange.Parse(TestPackageVersion),
    targetFramework: _testTargetframework,
    isGlobalTool: true,
    verifySignatures: false,
    cancellationToken: TestContext.CancellationToken);

For Action lambdas used with .Should().Throw<>(), also pass TestContext.CancellationToken:

// Before
Action secondCall = () => downloader.InstallPackage(..., verifySignatures: false);
secondCall.Should().Throw<ToolPackageException>()...;

// After
Action secondCall = () => downloader.InstallPackage(..., verifySignatures: false,
    cancellationToken: TestContext.CancellationToken);
secondCall.Should().Throw<ToolPackageException>()...;

🤖 Automated content by GitHub Copilot. Generated by the Build Failure Analysis workflow. · 294.5 AIC · ⌖ 7.94 AIC · ⊞ 5.3K · [◷]( · ◷)