// Regenerate Static Web Assets test baselines. USE FOR: fixing "generated manifest should match the expected baseline" errors, updating baseline JSON files after legitimate build output changes, understanding the baseline comparison system.
| name | swa-baseline-regeneration |
| description | Regenerate Static Web Assets test baselines. USE FOR: fixing "generated manifest should match the expected baseline" errors, updating baseline JSON files after legitimate build output changes, understanding the baseline comparison system. |
Baseline tests compare generated manifests against stored JSON files. When build output legitimately changes, baselines must be regenerated.
Expected collection to be empty because the generated manifest should match
the expected baseline. If the difference in baselines is expected, please
re-generate the baselines.
test/Microsoft.NET.Sdk.StaticWebAssets.Tests/StaticWebAssetsBaselines/
Two types per test:
| Pattern | Content |
|---|---|
{TestName}.Build.staticwebassets.json | Full build manifest (assets, endpoints, discovery patterns) |
{TestName}.Build.files.json | Expected files on disk |
{TestName}.Publish.staticwebassets.json | Publish manifest |
{TestName}.Publish.files.json | Publish file list |
Baselines use template variables for path portability:
${ProjectPath} — test project directory${RestorePath} — NuGet cache path${Tfm} — target framework monikerBaselines are embedded resources compiled into the test DLL via Assembly.GetManifestResourceStream(). The comparison flow:
staticwebassets.build.json manifest from intermediate outputAssertManifest(actual, LoadBuildManifest()) — templatizes actual paths (${ProjectPath}, etc.) and compares against the embedded baselineAssertBuildAssets(manifest, outputPath, intermediateOutputPath) — compares file listsThe templatization is done by StaticWebAssetsBaselineFactory.ToTemplate() in AspNetSdkBaselineTest.cs.
# 1. Build the test project to embed current baselines
.\artifacts\bin\redist\Debug\dotnet\dotnet.exe build `
test\Microsoft.NET.Sdk.StaticWebAssets.Tests\Microsoft.NET.Sdk.StaticWebAssets.Tests.csproj `
-c Debug --no-restore
# 2. Run affected tests with the regeneration flag
$env:ASPNETCORE_TEST_BASELINES = "true"
.\artifacts\bin\redist\Debug\dotnet\dotnet.exe test `
artifacts\bin\Microsoft.NET.Sdk.StaticWebAssets.Tests\Debug\net11.0\Microsoft.NET.Sdk.StaticWebAssets.Tests.dll `
--no-build --filter "FullyQualifiedName~AffectedTestClassName"
# 3. Clear the flag
Remove-Item Env:\ASPNETCORE_TEST_BASELINES
# 4. Rebuild the test project to embed the NEW baselines
.\artifacts\bin\redist\Debug\dotnet\dotnet.exe build `
test\Microsoft.NET.Sdk.StaticWebAssets.Tests\Microsoft.NET.Sdk.StaticWebAssets.Tests.csproj `
-c Debug --no-restore
# 5. Validate — run the same tests WITHOUT the flag
.\artifacts\bin\redist\Debug\dotnet\dotnet.exe test `
artifacts\bin\Microsoft.NET.Sdk.StaticWebAssets.Tests\Debug\net11.0\Microsoft.NET.Sdk.StaticWebAssets.Tests.dll `
--no-build --filter "FullyQualifiedName~AffectedTestClassName"
Step 2 writes new .json files to disk in StaticWebAssetsBaselines/, but they are embedded resources. The test DLL must be rebuilt (step 4) before the tests can read the updated baselines. Skipping step 4 means step 5 still compares against the old embedded baselines and will fail.
The repo includes src/RazorSdk/update-test-baselines.ps1:
# Regenerate:
dotnet test --no-build -c Release -l "console;verbosity=normal" <TestProject> `
-e ASPNETCORE_TEST_BASELINES=true --filter AspNetCore=BaselineTest
# Validate:
dotnet test --no-build -c Release -l "console;verbosity=normal" <TestProject> `
--filter AspNetCore=BaselineTest
| Class | Test Asset |
|---|---|
StaticWebAssetsAppWithPackagesIntegrationTest | RazorAppWithPackageAndP2PReference |
JsModulesPackagesIntegrationTest | RazorAppWithPackageAndP2PReference |
ScopedCssCompatibilityIntegrationTest | RazorAppWithPackageAndP2PReference |
ScopedCssPackageReferences | RazorAppWithPackageAndP2PReference |
LegacyStaticWebAssetsV1IntegrationTest | RazorAppWithPackageAndP2PReference |
StaticWebAssetsIntegrationTest | Various |
Run dotnet.Tests incrementally without a full build.cmd rebuild. Use after modifying source code in SDK projects to quickly build only changed projects, deploy their outputs into the redist SDK layout, and run tests against them.
Author end-to-end Static Web Assets integration tests that exercise MSBuild targets through build, publish, or pack. USE FOR: writing new SWA integration tests, choosing a test asset and base class, dynamically modifying projects at runtime, selecting the right manifest to assert on, verifying the full asset pipeline (primary, compressed, endpoints). DO NOT USE FOR: unit tests of individual tasks (write those directly), baseline regeneration (use swa-baseline-regeneration), troubleshooting failures (use swa-troubleshooting).
Understand and fix Static Web Assets Pack tests. USE FOR: fixing Pack test assertion failures after nupkg content changes, tracing MSBuild conditions to expected nupkg content, updating test assertions for new or changed package layouts, understanding conditional pack logic in .targets files.
Diagnose and fix common Static Web Assets test and build failures. USE FOR: analyzing CI failures, identifying root cause categories from error messages, fixing metadata propagation bugs, timing/ordering issues in MSBuild targets, test assertion mismatches.
Use this skill when you are implementing a change on src\StaticWebAssetsSdk and want to test the behavior locally to validate it works as expected.
Generate .NET SDK release notes by comparing two git branches, investigating PRs for user-facing changes, and producing a structured markdown document with contributor acknowledgments. Use this when asked to create or draft release notes for a new .NET SDK release.