Migrate DefineStaticWebAssets to multithreaded task execution#55117
Conversation
There was a problem hiding this comment.
Pull request overview
This PR migrates DefineStaticWebAssets to MSBuild multithreaded task execution by routing all path resolution through TaskEnvironment.ProjectDirectory (instead of process CWD) and updating related Static Web Assets normalization + cache invalidation behavior.
Changes:
- Marked
DefineStaticWebAssetsas[MSBuildMultiThreadableTask]and addedIMultiThreadableTask/TaskEnvironmentplumbing for MT-safe path resolution. - Updated Static Web Asset normalization/file resolution APIs to accept a
TaskEnvironmentso relative paths resolve against the project directory. - Reworked cache manifest path absolutization and cache input hashing to avoid CWD-sensitive metadata, adding MT-focused test coverage.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| test/Microsoft.NET.Sdk.StaticWebAssets.Tests/StaticWebAssets/DefineStaticWebAssetsMultiThreadingTest.cs | Adds tests validating MT-safe resolution against TaskEnvironment.ProjectDirectory and cache invalidation under a decoy process CWD. |
| src/StaticWebAssetsSdk/Tasks/DefineStaticWebAssets.cs | Switches candidate identity/content-root handling to use TaskEnvironment and MT-safe file resolution. |
| src/StaticWebAssetsSdk/Tasks/DefineStaticWebAssets.Cache.cs | Absolutizes cache manifest path via TaskEnvironment and updates cache input hashing to be MT/CWD independent. |
| src/StaticWebAssetsSdk/Tasks/Data/StaticWebAsset.cs | Extends asset construction/normalization to accept TaskEnvironment (fallback preserved for existing callers). |
- Treat null/empty/whitespace CacheManifestPath uniformly as "no cache":
switch to IsNullOrWhiteSpace and base the no-cache decision on the
normalized value, so a blank path never reaches GetAbsolutePath (which
throws) nor File.OpenWrite("") when persisting the cache manifest.
- Rename CacheInvalidatesRelativeCandidateWhenProjectFileChanges to
...WhenAssetFileChanges: the test mutates the candidate asset file's
contents/length, not a project file.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
jankratochvilcz
left a comment
There was a problem hiding this comment.
Automated MSBuild MT-migration + expert review. The migration itself is complete and correct — all CWD-dependent path resolution now flows through TaskEnvironment, and the cache-key change (dropping well-known %(FullPath)/%(ModifiedTime) in favor of task-computed full paths + Length + LastWriteTimeUtc.Ticks) is a genuine correctness improvement. No blocking issues. A few non-blocking suggestions inline.
OvesN
left a comment
There was a problem hiding this comment.
PR looks good, but I am not sure if all changes in cache-logic are necessary
Fixes: dotnet/msbuild#14040
Context
DefineStaticWebAssetsnow participates in MSBuild multithreaded task execution. Relative candidate paths, content roots, cache manifest paths, and cache input keys must resolve againstTaskEnvironment.ProjectDirectoryinstead of the process current directory.Changes Made
[MSBuildMultiThreadableTask],IMultiThreadableTask, andTaskEnvironmentsupport toDefineStaticWebAssets.TaskEnvironmentthroughStaticWebAsset.FromProperties, normalization, file resolution, and related content-root handling.CacheManifestPathrelative toTaskEnvironment.ProjectDirectory.DefineStaticWebAssetscache input hashing to avoid CWD-sensitiveFullPathandModifiedTimemetadata, hashing MT-safe candidate paths and file state instead.DefineStaticWebAssetsMultiThreadingTestcoverage for relative candidate/content-root resolution and cache invalidation under a decoy process CWD.Testing
dotnet build src/StaticWebAssetsSdk/Tasks/Microsoft.NET.Sdk.StaticWebAssets.Tasks.csproj— passed fornet11.0andnet472.dotnet test test/Microsoft.NET.Sdk.StaticWebAssets.Tests/Microsoft.NET.Sdk.StaticWebAssets.Tests.csproj --filter "FullyQualifiedName~DefineStaticWebAssetsMultiThreadingTest"— passed, 2 tests.