- 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)
Brennan
Pranav K
Doug Bunting
dotnet-maestro[bot]
William Godbe
Chris Ross
Artak
Matt Mitchell
Safia Abdalla
Javier Calvarro Nelson
DotNet Bot
dotnet-bot
James Newton-King
Steve Sanderson
Sourabh Shirhatti
John Luo