Fix compression input file resolution for esproj assets #52283
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
github-actions
bot
added
the
Area-AspNetCore
Contributor
|
Thanks for your PR, @@javiercn. |
Contributor
There was a problem hiding this comment.
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) overRelatedAssetOriginalItemSpec(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 |
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
javiercn
force-pushed
the
fix/esproj-compression-input-file-path
branch
from
702af2d to
bf590b9
Compare
MackinnonBuck
approved these changes
Jan 16, 2026
Comment on lines
+15
to
17
| // Check RelatedAsset first (the asset's Identity path) as it's more reliable. | ||
| // RelatedAssetOriginalItemSpec may point to a project file (e.g., .esproj) rather than the actual asset. | ||
| var relatedAsset = assetToCompress.GetMetadata("RelatedAsset"); |
Member
There was a problem hiding this comment.
Is this more reliable in the general case or only as it relates to the esproj SDK?
Member
Author
There was a problem hiding this comment.
Yeah, it is in general more reliable to first look if the file exists first for the related asset and the only fallback to the original spec if it doesn't. This logic is there because of the trick we have to do for webassembly apps.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
When compressing static web assets from esproj projects, the compression task incorrectly used the
.esprojproject 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
TryFindInputFilePathmethod inAssetToCompress.cscheckedRelatedAssetOriginalItemSpecbeforeRelatedAsset. The esproj SDK has a bug whereOriginalItemSpecgets set to the project file path instead of the asset file path (due to referencing%(CandidatePublishAssets.Identity)instead of%(CandidateBuildAssets.Identity)in theGetCurrentProjectBuildStaticWebAssetItemstarget).Fix
This PR changes the order of checks in
TryFindInputFilePathto preferRelatedAsset(the asset's Identity path) overRelatedAssetOriginalItemSpec.RelatedAssetcontains the correct file path even whenOriginalItemSpecis incorrect.Symptoms this fixes
.gz/.br) containing XML content of.esprojfile instead of compressed JavaScriptTesting
Added unit tests to verify:
RelatedAssetis preferred when both paths existRelatedAssetOriginalItemSpecwhenRelatedAssetdoesn't existAll existing tests continue to pass.
#Fixes #50987