Skip to content

Conversation

@javiercn
Copy link
Member

@javiercn javiercn commented Dec 24, 2025

Summary

When compressing static web assets from esproj projects, the compression task incorrectly used the .esproj project file as the input instead of the actual JavaScript asset file. This resulted in compressed files (.gz/.br) containing XML content instead of compressed JavaScript.

Root Cause

The TryFindInputFilePath method in AssetToCompress.cs checked RelatedAssetOriginalItemSpec before RelatedAsset. The esproj SDK has a bug where OriginalItemSpec gets set to the project file path instead of the asset file path (due to referencing %(CandidatePublishAssets.Identity) instead of %(CandidateBuildAssets.Identity) in the GetCurrentProjectBuildStaticWebAssetItems target).

Fix

This PR changes the order of checks in TryFindInputFilePath to prefer RelatedAsset (the asset's Identity path) over RelatedAssetOriginalItemSpec. RelatedAsset contains the correct file path even when OriginalItemSpec is incorrect.

Symptoms this fixes

  • Compressed files (.gz/.br) containing XML content of .esproj file instead of compressed JavaScript
  • JavaScript interop failures in Blazor apps using esproj-based libraries (e.g., Fluent UI)

Testing

Added unit tests to verify:

  • RelatedAsset is preferred when both paths exist
  • Fallback to RelatedAssetOriginalItemSpec when RelatedAsset doesn't exist
  • Error handling when neither path exists
  • Specific esproj scenario with project file vs JS file

All existing tests continue to pass.

#Fixes #50987

When compressing static web assets from esproj projects, the compression
task incorrectly used the .esproj project file as the input instead of
the actual JavaScript asset file. This happened because the code checked
RelatedAssetOriginalItemSpec before RelatedAsset.

The esproj SDK has a bug where OriginalItemSpec gets set to the project
file path instead of the asset file path (due to referencing
%(CandidatePublishAssets.Identity) instead of %(CandidateBuildAssets.Identity)
in the GetCurrentProjectBuildStaticWebAssetItems target).

This fix changes the order of checks in TryFindInputFilePath to prefer
RelatedAsset (the asset's Identity path) over RelatedAssetOriginalItemSpec.
RelatedAsset contains the correct file path even when OriginalItemSpec
is incorrect.

Symptoms this fixes:
- Compressed files (.gz/.br) containing XML content of .esproj file
- JavaScript interop failures in Blazor apps using esproj-based libraries

Added unit tests to verify:
- RelatedAsset is preferred when both paths exist
- Fallback to RelatedAssetOriginalItemSpec when RelatedAsset doesn't exist
- Error handling when neither path exists
- Specific esproj scenario with project file vs JS file
Copilot AI review requested due to automatic review settings December 24, 2025 17:31
@github-actions github-actions bot added the Area-AspNetCore RazorSDK, BlazorWebAssemblySDK, dotnet-watch label Dec 24, 2025
@dotnet-policy-service
Copy link
Contributor

Thanks for your PR, @@javiercn.
To learn about the PR process and branching schedule of this repo, please take a look at the SDK PR Guide.

Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR fixes a critical bug in the compression of static web assets from esproj projects. Previously, compressed files contained XML content from the .esproj project file instead of the actual JavaScript content because the compression task used the wrong file path.

Key Changes:

  • Reordered file path resolution to prefer RelatedAsset (the asset's Identity) over RelatedAssetOriginalItemSpec (which may incorrectly reference the project file)
  • Added comprehensive unit tests covering the new resolution order and edge cases
  • Updated error message parameter order to match the new check sequence

Reviewed changes

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

File Description
src/StaticWebAssetsSdk/Tasks/Utils/AssetToCompress.cs Changed TryFindInputFilePath to check RelatedAsset first before falling back to RelatedAssetOriginalItemSpec, and updated error message parameter order to reflect the new sequence
test/Microsoft.NET.Sdk.StaticWebAssets.Tests/StaticWebAssets/AssetToCompressTest.cs Added new test class with 6 comprehensive test cases verifying the corrected file resolution order, fallback behavior, error handling, and the specific esproj scenario

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Area-AspNetCore RazorSDK, BlazorWebAssemblySDK, dotnet-watch

Projects

None yet

Development

Successfully merging this pull request may close these issues.

StaticWebAssets of esproj: wrong content in compressed files

2 participants