de177e3a80
Description This pull request addresses an issue reported by users in #27752 in which the integrity checks that occur in the browser for assemblies loaded by a Blazor WebAssembly application incorrectly fail after a user upgrades their application from one version to another. This occurs because our MSBuild targets don't correctly update the compressed assemblies when a user upgrades, which results in the non-compressed assemblies and integrity hash pointing to the new version but the compressed assembly pointing to the old version which causes an integrity check failure. Technical Description The GzipCompression task iterates through a list of provided FilesToCompress and determines whether or not a file needs to be updated by checking to see if the input file is older than the compressed file that already exists in the intermediate output path. aspnetcore/src/Components/WebAssembly/Sdk/src/GZipCompress.cs Lines 45 to 50 in 45540f7 if (File.Exists(outputRelativePath) && File.GetLastWriteTimeUtc(inputPath) < File.GetLastWriteTimeUtc(outputRelativePath)) { // Incrementalism. If input source doesn't exist or it exists and is not newer than the expected output, do nothing. Log.LogMessage(MessageImportance.Low, $"Skipping '{inputPath}' because '{outputRelativePath}' is newer than '{inputPath}'."); return; } The outputRelativePath used in the comparison above is a hashed value generated from the the RelativePath which is set to wwwroot/_framework/Microsoft.CSharp.dll for example. If a user changes from version 5.0-rc2 to 5.0 of a package, then the RelativePath will be the same whereas the FullPath will be ~/.nuget/packages/microsoft.netcore.app.runtime.browser-wasm/5.0.0/runtimes/browser-wasm/lib/net5.0/Microsoft.CSharp.dll compared to /Users/captainsafia/.nuget/packages/microsoft.netcore.app.runtime.browser-wasm/5.0.0-rc.2.20475.5/runtimes/browser-wasm/lib/net5.0/Microsoft.CSharp.dll. By passing the FullPath we are able to account for the package version in the generated output which will cause a unique hash to be generated for different package versions and the File.Exists check in the conditional to fail and result in the new gzipped outputs being generated as expected. Customer Impact This bug was reported by multiple customers after the release of .NET 5. The bug makes the upgrade experience between .NET versions a lot rougher since users run into unexpected exceptions in their apps at runtime. Viable workarounds for this include running dotnet clean before building the project after an upgrade. Regression? This is not a regression, but the issue is more serious since users are upgrading from Blazor WASM 3.2 to Blazor WASM 5 or from a 5.0 RC to the RTM. Risk The risk associated with this change is relatively slim, because: Manually validation was completed The behavior implemented in the changeset mimicks what we already do in the Brotli compression The impact area is only limited to Blazor WASM apps running in development |
||
|---|---|---|
| .azure/pipelines | ||
| .config | ||
| .github | ||
| .vscode | ||
| docs | ||
| eng | ||
| src | ||
| .editorconfig | ||
| .gitattributes | ||
| .gitignore | ||
| .gitmodules | ||
| .vsconfig | ||
| AspNetCore.sln | ||
| CODE-OF-CONDUCT.md | ||
| CONTRIBUTING.md | ||
| Directory.Build.props | ||
| Directory.Build.targets | ||
| LICENSE.txt | ||
| NuGet.config | ||
| README.md | ||
| SECURITY.md | ||
| THIRD-PARTY-NOTICES.txt | ||
| activate.ps1 | ||
| activate.sh | ||
| build.cmd | ||
| build.ps1 | ||
| build.sh | ||
| clean.cmd | ||
| clean.ps1 | ||
| clean.sh | ||
| dockerbuild.sh | ||
| global.json | ||
| restore.cmd | ||
| restore.sh | ||
| startvs.cmd | ||
README.md
ASP.NET Core
ASP.NET Core is an open-source and cross-platform framework for building modern cloud based internet connected applications, such as web apps, IoT apps and mobile backends. ASP.NET Core apps run on .NET Core, a free, cross-platform and open-source application runtime. It was architected to provide an optimized development framework for apps that are deployed to the cloud or run on-premises. It consists of modular components with minimal overhead, so you retain flexibility while constructing your solutions. You can develop and run your ASP.NET Core apps cross-platform on Windows, Mac and Linux. Learn more about ASP.NET Core.
Get Started
Follow the Getting Started instructions in the ASP.NET Core docs.
Also check out the .NET Homepage for released versions of .NET, getting started guides, and learning resources.
See the Triage Process document for more information on how we handle incoming issues.
How to Engage, Contribute, and Give Feedback
Some of the best ways to contribute are to try things out, file issues, join in design conversations, and make pull-requests.
- Download our latest daily builds
- Follow along with the development of ASP.NET Core:
- Community Standup: The community standup is held every week and streamed live to YouTube. You can view past standups in the linked playlist.
- Roadmap: The schedule and milestone themes for ASP.NET Core.
- Build ASP.NET Core source code
- Check out the contributing page to see the best places to log issues and start discussions.
Reporting security issues and bugs
Security issues and bugs should be reported privately, via email, to the Microsoft Security Response Center (MSRC) secure@microsoft.com. You should receive a response within 24 hours. If for some reason you do not, please follow up via email to ensure we received your original message. Further information, including the MSRC PGP key, can be found in the Security TechCenter.
Related projects
These are some other repos for related projects:
- Documentation - documentation sources for https://docs.microsoft.com/aspnet/core/
- Entity Framework Core - data access technology
- Extensions - Logging, configuration, dependency injection, and more.
Code of conduct
See CODE-OF-CONDUCT