* 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
Razor requires referencing two different versions of Roslyn
Razor compiler (rzc) that ships as part of the SDK. rzc ships copies of compiler binaries (Microsoft.CodeAnalysis.CSharp and Microsoft.CodeAnalysis.Common).
Razor runtime compilation is shipped as a NuGet package and needs to reference a version of Roslyn that ships as a NuGet package.
Roslyn doesn't follow the runtime ship schedule so to reliably the 2nd item, ASP.NET Core manually updates this package version. As part of 5.0.1, it was discovered that there's two different versions of these binaries in the SDK (a 3.8.0 version carried by the compiler and a 3.7.0 version carried by Razor). This is a bit vexxing, more so in source build which only builds the newer version.
Fixes#28096
Description
Update the Roslyn version referenced by Razor to 3.8.0
Customer impact
Razor compilation uses a newer version of the compiler consistent with the rest of the SDK.
Users updating to the 5.0.1 version of runtime compilation package will now use a newer version of the compiler. While it's slightly unusual to update a reference by a minor version as part of a patch release, we do not see users taking a hard dependency on the compiler version to be affected by this.
Regression
No
Risk
Low.
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
[release/5.0] Update dependencies from dotnet/efcore dotnet/runtime
- Return to RTM version of a package
- dotnet/runtime is not currently producing a useful Microsoft.Extensions.Internal.Transport
- quickest way to ignore the bad stuff is to pin the package here
- Update eng/Version.Details.xml
- Update eng/Version.Details.xml
- Update eng/Version.Details.xml
- Unpin Microsoft.Extensions.Internal.Transport
The browser refresh mechansim used by dotnet-watch and VS modifies HTML content. The modified content includes
a script block that has a WebSocket url that changes for each new execution of dotnet watch run (not rebuilds, but watch itself).
HTML content can come from views or static html files on disk. For the latter, ASP.NET Core participates in browser caching by sending (and invalidating) etag headers.
One way to fix this problem is remove or modify the etag headers. The risk here is that might cause differences in behavior in development users may come to rely on that are unavailable in production. This change instead modifies the HTML content so the output is always consistent and consequently safe to cache. The dynamic content is served separately by the injected middleware.
This change fixes the issue of multiple instances of dotnet-watch. While this issue may crop up if you alternate between dotnet run and dotnet watch run but we haven't seen this being an issue as yet.
Fixes#27548
Summary
Running dotnet watch run multiple times in Blazor WASM apps (or any app that serves static html files) can produce console errors and prevent the browser refresh feature from working. Given that we've been telling our users to use dotnet watch run as their primary way to work outside of VS, it's likely more users would run in this.
Customer impact
A hard browser refresh (Ctrl + R) is needed to get the refresh behavior to work.
Regression
No. This has existed since the feature was introduced we did not get reports of it
Risk
Low. The fix is isolated to dotnet-watch and VS's browser refresh mechanism which is in preview. The change was tested locally, but if there's a regression or if the change interferes with user's workflow, users have the ability to disable this feature.
Description
HTML <a> elements within shadow roots are invisible to the link click interception code. So when an end user clicks on a link that's inside the shadow root of a custom element, it triggers a full page load instead of a client-side navigation.
Customer Impact
Reported by a customer at #27070. There's no reasonable workaround (besides not using custom elements and shadow DOM).
The impact is that if you're using a library of custom HTML elements, which typically use ShadowDOM to render, then if you use them to produce any links, then those links will seem broken to the end user (as in, they trigger a full-page reload, destroying any app state in WebAssembly memory or discarding the Blazor Server circuit).
Regression?
No, this has always been the case. However, the use of custom elements and ShadowDOM is a growing area, especially as we try to guide customers to use custom elements like the FAST components.
The fact that this use case is growing in importance makes it relevant to consider patching rather than waiting a full year for 6.0.
We don't have to ship this in 5.0.1, but we should be prepared to ship it in a patch reasonably soon.
Risk
This changes the logic for processing clicks on all links, not just the ones in shadow roots. Although I'm not aware of any cases where the new logic might fail, and all our E2E tests pass, maybe I missed some case. It's unfortunate we don't have any opportunity to put this in front of customers any any preview form.
Description
Fixes#27494
A community PR introduced new overloads to ControllerBase for SignIn. The new overload throws due to an existing check which blocks when the scheme is null. The fix is to remove this unnecessary check. Note SignOutResult already had test coverage for this usage and is unaffected
Customer Impact
The bug was reported by a customer trying to use the new overload. The fix enables the method to be used.
Regression?
No
Risk
Low as this is a new API, and the api was unuseable in its current form.
Description
This PR updates the version of the caniuse-lite dependency to the latest version on our React and React/Redux SPA templates. The caniuse-lite dependency provides a database of browser features and their support across different browsers (as seen in caniuse.com). We were getting a warning because the dependency was out-of-date which meant that it was reporting compatibility info that was no longer accurate.
This PR also updates the version of node-sass to the latest version which no longer depends on the no-longer-supported Python 2.
Customer Impact
This bug was discovered during CTI validation.
This bug has a low severity because the user application can still run although JavaScript-based build tooling might report that the developer is leveraging browser features that aren't supported by the browser when they actually are.
Users can workaround this by running npx browserslist@latest --update-db inside their ClientApp directory. Users can also manually upgrade node-sass to v5 by editing their package.json file.
Regression?
No.
Risk
Low risk, because:
Change was validated manual
This fix applies the changes recommended by the browserlist library
* Move all PublicAPI.Unshipped.txt files to PublicAPI.Shipped.txt
- we have now shipped this API surface
* Add eng/PublicAPI.empty.txt file
- make it easier to add new implementation projects
* Add missing public API baseline files
- #26784 part 1/2
- a few unexpected files turned up missing beyond the #26784 list…
* Reference Microsoft.CodeAnalysis.PublicApiAnalyzers more often
- #27484 part 2/2
- emit errors when API baseline files are missing
- update categorization of some projects
- specification tests are not implementation projects
- but _were_ project reference providers (keep that)
- correct `$(IsTestAssetProject)` setting for Razor shims et cetera
- correct `$(IsSampleProject)` setting for casing of some Sample directories
- Microsoft.AspNetCore.Analyzer.Testing should be treated as test asset
- add `$(AddPublicApiAnalyzers)` property to support overrides
- e.g. for `msbuild` task projects and tools
nit:
- remove useless `$(IsTestProject)` setting in a specification test project
- wrap some long `Condition`s
* Do not run public API analyzer in `RazorCoreCompile` target
* Remove old `$(EnableApiCheck)` settings
- property does nothing
- also remove a dangling ApiCheck comment
* Ensure AppLocalResolver handles package with multiple libs
This was failing to pass references to a package which contains more
than one lib.
* Use `AppBaseCompilationAssemblyResolver` in `DiagnosticProject`
* Fix, then reduce use of `TestPathUtilities.GetSolutionRootDirectory(...)` (#27404)
- do not traverse up past the `$(RepoRoot)` when running tests locally
- if `$(RepoRoot)` is reached, search down for named `*.slnf` file
- find `*.slnf` file when `$(OutputPath)` is under artifacts/bin/
- analyzer test projects publish needed files anyhow
- remove `GetProjectDirectory()` helpers
Co-authored-by: Doug Bunting <6431421+dougbu@users.noreply.github.com>
* Move to 5.0.1 versions
* Move to GA .NET SDK
- required for some tests to pass
* Remove feeds that won't be needed after 5.0.0 is GA
* Cherry-pick `$(CrossgenOutput)` and Directory.Build.*.in changes from master
- [master] Update dependencies from dotnet/runtime dotnet/efcore (#26788)
- 219ecd688012
- when project template tests run test assets, need latest shared Fx bits
- hit `BadImageFormatException`s otherwise
- test projects build against uploaded packages
- those packages reference the 5.0.1 shared framework
- the ASP.NET parts of the 5.0.1 shared Fx are `crossgen`ed to target Windows
- Use runtime and ref/ assemblies matching repo in Helix testing
- add Directory.Build.*.in files based on project template test infrastructure
- use files as import boundary where the project doesn't create its own Directory.Build.* files
- ensure `dotnet-watch` tests also use the latest runtime and ref/ assemblies
- Extend Helix Directory.Build.* workarounds
- generate Directory.Build.* files when restoring any projects
- include generated files in Helix runs needing the latest runtime
- copy generated files when testing `dotnet-watch` locally
- include generated content in Microsoft.NET.Sdk.BlazorWebAssembly.IntegrationTests test assets
- remove duplicate settings from existing Directory.Build.* files
- ensure shared framework and targeting packs are laid out under .dotnet/ before test assets restore
- Disable `crossgen` when building for Helix runs
- make `$(CrossgenOutput)` property override-able
- use override in CI jobs that submit to other platforms
- for now, leave the ARM64 Helix jobs alone (build on Ubuntu, run in Debian)
* Correct an `$(IsTestAssetProject)` setting
- affected projects are all test assets or provide test support
- without this, a number of the projects are incorrectly marked as shipping
* Baseline released 5.0.0 packages
- this is a complete rewrite of eng/Baseline.xml
- based on the 5.0.0 MergedManifest.xml file
* Add 5.0.0 PackageOverrides.txt and PlatformManifest.txt files
- need consistent versions when servicing targeting packs
Co-authored-by: dotnet-maestro[bot] <42748379+dotnet-maestro[bot]@users.noreply.github.com>
- run aspnetcore-helix-matrix at 09:00 UTC
- the first run of master starts at noon UTC
- looks highly unlikely new run would take 3 hours
- add rolling builds of aspnetcore-quarantined-pr
nit: make target branches for PR builds explicit
- we don't support Helix testing of 3.1 or older
Safia Abdalla
Steve Sanderson
Sourabh Shirhatti
John Luo
Pranav K
William Godbe
Javier Calvarro Nelson
dotnet-maestro[bot]
Jan Vorlicek
Brennan
Matt Mitchell
Hao Kung
Doug Bunting
Eric StJohn