- cherry-picked from 1a241fcfc2f8 in 'master' branch
- avoid new CS1504 errors because compiler can't find the ErrorPage.cshtml file
- we override Arcade's `$(MicrosoftCodeAnalysisCSharpVersion)`
- use new option in GeneratePage.ps1 script
- script also did not know `RazorSyntaxGenerator` had moved to this repo
- reflect latest `RazorSyntaxGenerator` processing
- run GeneratePage.ps1
- update README.md
nits:
- quote all paths in GeneratePage.ps1 script
- remove passive voice in README.md
## Description
VS has a feature of adding gRPC service reference to a project using UI. Currently that experience has no easy way to differentiate between Blazor Server and Blazor WebAssembly projects. As a result, adding gRPC reference using VS feature adds the wrong gRPC package (Grpc.AspNetCore), instead of adding `Grpc.Net.Client` and `Grpc.Net.Client.Web`, per our documentation. The package which is wrong adds framework reference transitively, which is not supported on WebAssembly.
This change adds a unique WebAssembly capability to all Blazor WebAssembly projects (through the SDK) so VS can build unique experiences those projects and also address that bug.
## Customer Impact
This particular change has no customer impact, but it will enable VS to fix their experience tracked by [this AzDO issue](https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1242008)
## Regression?
- [ ] Yes
- [x] No
## Risk
- [ ] High
- [ ] Medium
- [x] Low
[Justify the selection above]
## Verification
- [ ] Manual (required)
- [ ] Automated
Not applicable as this change has no functional impact. The follow-up change is on the VS side to utilize this change and differentiate projects.
## Packaging changes reviewed?
- [ ] Yes
- [ ] No
- [x] N/A
Addresses https://github.com/dotnet/aspnetcore/issues/28716
#### Description
This PR updates the version of the MSAL.js dependency that we redistribute in our Authentication.Msal library in response to user requests and recommendation from the MSAL team.
#### Technical Description
This PR contains some code changes in response to some changes in type definition over in MSAL.js:
- https://github.com/AzureAD/microsoft-authentication-library-for-js/pull/2105
- https://github.com/AzureAD/microsoft-authentication-library-for-js/pull/2512
#### Customer Impact
Without these changes, if users want to pick up required bug fixes in the downstream MSAL.js library, they would have to compile their own version of JavaScript dependencies and integrate them into their project.
This PR allows users to consume bug fixes blocking customer login and platform support without having to put in difficult workarounds.
#### Regression?
- [ ] Yes
- [X] No
#### Risk
- [ ] High
- [ ] Medium
- [X] Low
Change contains no breaking changes and was made on recommendation of the MSAL team. Manual verification completed.
#### Verification
- [X] Manual (required)
- [ ] Automated
Verified navigating to the authorized-only fetch data page, logging in, confirming redirect, logging out, logging in again on:
- Azure B2C + Blazor WASM Hosted
- Azure B2C + Blazor Standalone
- Azure AAD + Blazor WASM Hosted
- Azure AAD + Blazor WASM Standalone
#### Packaging changes reviewed?
- [ ] Yes
- [ ] No
- [X] N/A
Addresses https://github.com/dotnet/aspnetcore/issues/29010, https://github.com/dotnet/aspnetcore/issues/28969, https://github.com/dotnet/aspnetcore/issues/28956
## Description
Updates outdated dependencies for the Angular, React and React redux templates.
## Customer Impact
Customers creating new projects get obsolete versions of some javascript dependencies and need to update them manually.
## Regression?
- [ ] Yes
- [X] No
[If yes, specify the version the behavior has regressed from]
## Risk
- [ ] High
- [ ] Medium
- [X] Low
The changes only update dependencies and have been tested manually.
## Verification
- [X] Manual (required)
- [ ] Automated
## Packaging changes reviewed?
- [ ] Yes
- [ ] No
- [X] N/A
Description
#28017
In 5.0.1 we fixed a publish scenario where Blazor webassembly wasn't respecting the StaticWebAssetBasePath defined for the project. Unfortunately the logic for handling the path composition was not robust enough and while it fixed the publish output layout, it introduced an integration issue later on at runtime.
The current fix makes the handling of the path more tolerant to initial and final slashes and includes a new end to end test that validates this scenario.
Customer Impact
Customers can't host blazor applications outside the root path (/)
Regression?
Yes. Worked in 3.2
Risk
Low.
We've included additional tests and E2E automation to verify this case.
Validation
Automated
Manual
* Add legacy 3.1 fork of the whitespace tests, with baselines based on 5.0 behavior
* Remove non-applicable Legacy_3_1_WhiteSpace_WithPreserveWhitespace test
* Set the legacy tests to run with RazorLanguageVersion.Version_3_0
* Add legacy fork of the whitespace pass
* Consolidate both versions of whitespace pass and show it doesn't affect the baselines
* Revert BOM change
* Fix test
* Unset delegation propery from source queue. This removes the process from the target URL group and allows the delegation rule to be added back later on in the processes lifetime
* Add test
* Add disposing pattern
Co-authored-by: Nolan Glore <nglore@microsoft.com>
Remove MicrosoftAspNetCoreAuthenticationJwtBearerPackageVersion and MicrosoftAspNetCoreAuthenticationOpenIdConnectPackageVersion if there are not need eg. user wants only OpenApi.
Co-authored-by: Andrzej Król <andkrul@gmail.com>
The RazorTagHelper task in the SDK is invoked by targets outside the SDK.
Consequently, any new requirements on the tasks need to be compatible with these versions.
In 5.0, we changed the task to expect the path to be passed in by the ToolExe property. This changes allows
using dotnet.exe from the ambient PATH to be used instead (the previous behavior)
Description
We introduced a public property as part of #27907 to enable users to opt-in. Turns out that this caused issues since we didn't update the target pack.
As a result, the Razor compiler treats this new property as a regular HTML attribute (of type string) instead of as a boolean.
In turn this causes the template to error at runtime when the application starts.
Customer Impact
Customers using 5.0.1 won't be able to create and run new blazor apps out of the box. They can fix the template code by preceding the true value in the attribute with @ to force the compiler to interpret it as C#. (Which is the same fix we are applying).
Regression?
Yes, 5.0.0. Users were able to create new blazor templates without this issue.
Risk
Low. We've manually validated the fix against a new project from a 5.0.1 template.
[release/5.0] Update dependencies from dotnet/efcore dotnet/runtime
- Merge branch 'release/5.0' into darc-release/5.0-d4478e43-6d04-47a1-8a7c-c6c2dcd90d64
- Tweak tests
- Remove Extensions.Internal.Transport from Runtime
- Microsoft.AspNetCore.App.Runtime project does not expect compilation-only references
- !fixup! Rearrange a `Condition`
- slight change to 49cc13cb5ac6 workaround
- Do not compile against assemblies with newer assembly versions
- avoid problems with e.g. System.Extensions.DependencyInjection in 5.0.1
- Revert "Remove package version pinning for ref/ assemblies in servicing (#25851)"
- dotnet/runtime assembly versions are unexpectedly changing in servicing
This reverts commit bfc1ec6792.
- Update `SharedFxTests` to handle dotnet/runtime version changes
- assemblies with non-0.0 versions end up in Microsoft.AspNetCore.App
- future-proofs these tests because more dotnet/runtime versions may change
- !fixup! Revert of bfc1ec6792 messed up `RepoTasks`
- need the RTM-versioned packages on all platforms
- we only target `net472` on Windows
In 3.2, Blazor WebAssembly had a feature which allowed prefix the relative path within the PublishDir
by configuring a StaticWebAssetBasePath property in the project file. As part of migrating to 5.0, this
feature was (accidentally) not brought forward which is remedied by this commit.
* Use StaticWebAssetBasePath to calculate asset base paths
* Add publish tests to verify hosted and standalone scenarios
Fixes https://github.com/dotnet/aspnetcore/issues/27776
Co-authored-by: Artak <34246760+mkArtakMSFT@users.noreply.github.com>
Browsers may not correctly resolve the machine's timezone in some cases. In the current implementation,
this results in an exception being thrown by .NET Core (WASM). This code defaults the timezone to UTC
when the timezone cannot be resolved.
Fixes https://github.com/dotnet/runtime/issues/44154
Port of https://github.com/dotnet/aspnetcore/pull/27444
Co-authored-by: Artak <34246760+mkArtakMSFT@users.noreply.github.com>
Description
This package is a collection of tests which we have shipped which allows customers who have implemented their own identity stores to verify that their stores behave as expected. Our quarantine process introduced some internal dependencies to this package during 5.0, which resulted in us no longer shipping this package.
Customer impact
Customers were relying on using this library to ensure that their implementations worked against our identity manager implementations.
Regression
Yes. Regression from 3.2
Risk
Low. We currently run our CI tests against this package, this just allows customers to once again be able to run our tests on their CI builds.
Description
In 5.0 we introduced two features on Blazor routing that enable users to write routing templates that match paths with variable length segments. These two features are optional parameters {parameter?} and catch all parameters {*catchall}.
Our routing system ordered the routes based on precedence and the (now false) assumption that route templates would only match paths with an equal number of segments.
The implementation that we have worked for naïve scenarios but breaks on more real world scenarios. The change here includes fixes to the way we order the routes in the route table to match the expectations as well as fixes on the route matching algorithm to ensure we match routes with variable number of segments correctly.
Customer Impact
This was reported by customers on #27250
The impact is that a route with {*catchall} will prevent more specific routes like /page/{parameter} from being accessible.
There are no workarounds since precedence is a fundamental behavior of the routing system.
Regression?
No, these Blazor features were initially added in 5.0.
Risk
Low. These two features were just introduced in 5.0 and their usage is not as prevalent as in asp.net core routing. That said, it's important to fix them as otherwise we run the risk of diverting in behavior from asp.net core routing and Blazor routing, which is not something we want to do.
We have functional tests covering the area and we've added a significant amount of unit tests to validate the changes.
For 5.0, we made a change to exclude .Views.dll from the single file bundle as a reaction
to changes in bundling. However the SDK change also applied to .NET 3.1 apps. This change
limits the exclusion to 5.0 and newer apps.
Fixes https://github.com/dotnet/aspnetcore/issues/27831
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
Safia Abdalla
Pranav K
Sayed Ibrahim Hashimi
Chris Ross
DotNet Bot
dotnet-bot
Brennan
Doug Bunting
Matt Mitchell
William Godbe
Artak
Javier Calvarro Nelson
Steve Sanderson
Sourabh Shirhatti
John Luo
dotnet-maestro[bot]
Jan Vorlicek
Hao Kung