## 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
#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
[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
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.
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
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.
* 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>
* !!! Correct condition controlling `public` API analysis !!!
- #26785 demonstrated analyzers were inoperable
* Remove unused `public` API files
* Update `public` API files
- three Components files were missing `#nullable enable`
- `nullable` annotations missing or out-of-date elsewhere
* Ignore `public` API files completely during source build
- do not warn about unused files
* Update more `public` API files
Using Browser.Exists is equivalent to Browser.FindElement except it provides better logs
and diagnostics when the assertion fails. The additional waits will also rule out
failures due to the browser taking time to update possibly improving stability.
I looked at the implementation of WebDriverWait to verify that using it will not
introduce additional delays to our tests.
* Attempt to read the logs from the browser
Seleniunm currently does not return log messages (See https://github.com/SeleniumHQ/selenium/issues/8229).
This making figuring out blazor WASM test failures a lot harder.
This change adds some JS to the test apps to read the console output.
* WIP
The package was marked as non-shipping but we continued to build and test it. This change
removes it. A copy of this code exists in asplabs so all is not lost.
* Add tests for failing disconnect scenarios
* Remove beforeunload call and add public API
* Add additional test case
* Update src/Components/test/testassets/BasicTestApp/GracefulTermination.razor
Co-authored-by: Steve Sanderson <SteveSandersonMS@users.noreply.github.com>
Co-authored-by: Steve Sanderson <SteveSandersonMS@users.noreply.github.com>
* Detect culture change in .NET
With ICU sharding enabled, blazor wasm attempts to detect if the application culture was changed by the
application code as part of Program.MainAsync and tell them they need to opt out of sharding.
Prior to this change, Blazor compared the .NET culture string with a JS representation for language. With iOS 14,
the two culture strings differ in casing which prevents the use of any Blazor WASM app the latest version installed.
As part of this change, the comparison is performed entirely in .NET which avoids relying on the JS representation.
* Fixups
* E2E test cases for Virtualize data refresh
* Expose public RefreshDataAsync API
* Optimize: don't instantiate CancellationTokenSource when it won't be used
* For in-memory data, refresh automatically on each render cycle
* Fix typo
This change is prep for post build signing. When PostBuildSign=true, signing is not performed during the build. Instead, pass the top-level artifacts that are signable to PushToAzureDevOpsArtifacts (via Publish.proj).
Also fix up ArtifactsDir. As far as I can tell, it's been fixed up in Arcade to always include the trailing \, and Publish.proj should no longer be messed up.
* Fix chrome/selenium tests (#25330)
* Revert "Disable failing/hanging tests due to Chrome/Selenium issue (#25323)"
This reverts commit 332f1504128a63431cb67830703922cdeefee525.
* Update Selenium to latest
* Update API
* Try specifying a version
* Update Selenium to 4.0.0-beta5
* Disable browser log tests
* Fix components e2e tests and disable blazor standalone template test
* Disable tests using browser log
* Disable template test
* Avoid using .NET formatted strings in tests
* Annotate BasicTestApp suggesting that it needs the all globalization data
* Culture specific formatting relies on the ICU data carried by the OS. This
causes issues in our tests if WebAssembly carries a different set than the OS. Instead
updating these tests to use hardcoded strings.
* Additionally fixing an issue where some projects in the solution were using tasks from
the .dotnet SDK rather than the local copy of the SDK. This was causing issues building locally.
Co-authored-by: Pranav K <prkrishn@hotmail.com>
* Fix caching of WASM resources on localhost
* Fix test server startup
* Add missing server variant of VirtualizationTest
* Make test namespaces consistent
* Fix VirtualizationTest cases
* Update BootResourceCachingTest
[release/5.0-rc2] Update dependencies from dotnet/arcade dotnet/runtime dotnet/efcore
- Updates:
- System.ComponentModel.Annotations: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- System.Diagnostics.DiagnosticSource: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- System.Diagnostics.EventLog: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- System.DirectoryServices.Protocols: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- Microsoft.Extensions.Logging.Abstractions: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- Microsoft.Extensions.Logging.Configuration: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- Microsoft.Extensions.Logging.Console: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- Microsoft.Extensions.Logging.Debug: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- Microsoft.Extensions.Logging.EventLog: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- Microsoft.Extensions.Logging.EventSource: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- Microsoft.Extensions.Logging.TraceSource: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- Microsoft.Extensions.Options: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- Microsoft.Extensions.Options.ConfigurationExtensions: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- Microsoft.Extensions.Options.DataAnnotations: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- Microsoft.Extensions.Primitives: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- Microsoft.Extensions.Logging: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- Microsoft.Extensions.Internal.Transport: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- Microsoft.Extensions.Http: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- Microsoft.Extensions.Hosting.Abstractions: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- Microsoft.Extensions.Caching.Abstractions: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- Microsoft.Extensions.Caching.Memory: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- Microsoft.Extensions.Configuration: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- Microsoft.Extensions.Configuration.Abstractions: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- Microsoft.Extensions.Configuration.Binder: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- Microsoft.Extensions.Configuration.CommandLine: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- Microsoft.Extensions.Configuration.EnvironmentVariables: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- Microsoft.Extensions.Configuration.FileExtensions: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- Microsoft.Extensions.Configuration.Ini: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- Microsoft.Extensions.Configuration.UserSecrets: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- Microsoft.Extensions.Configuration.Xml: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- Microsoft.Extensions.DependencyInjection: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- Microsoft.Extensions.DependencyInjection.Abstractions: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- Microsoft.Extensions.DependencyModel: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- Microsoft.Extensions.FileProviders.Abstractions: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- Microsoft.Extensions.FileProviders.Composite: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- Microsoft.Extensions.FileProviders.Physical: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- Microsoft.Extensions.FileSystemGlobbing: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- Microsoft.Extensions.HostFactoryResolver.Sources: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- Microsoft.Extensions.Hosting: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- Microsoft.Extensions.Configuration.Json: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- Microsoft.NETCore.App.Runtime.win-x64: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- Microsoft.NETCore.BrowserDebugHost.Transport: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- Microsoft.NETCore.Platforms: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- Microsoft.Win32.Registry: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- Microsoft.Win32.SystemEvents: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- Microsoft.NETCore.App.Internal: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- Microsoft.NETCore.App.Ref: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- System.Drawing.Common: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- System.Threading.Channels: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- System.Windows.Extensions: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- System.Text.Json: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- System.Text.Encodings.Web: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- System.ServiceProcess.ServiceController: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- System.IO.Pipelines: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- System.Net.Http.Json: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- System.Net.Http.WinHttpHandler: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- System.Net.WebSockets.WebSocketProtocol: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- System.Reflection.Metadata: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- System.Runtime.CompilerServices.Unsafe: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- System.Security.AccessControl: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- System.Security.Cryptography.Cng: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- System.Security.Cryptography.Pkcs: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- System.Security.Cryptography.Xml: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- System.Security.Permissions: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- System.Security.Principal.Windows: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- System.Resources.Extensions: from 5.0.0-rc.2.20452.8 to 5.0.0-rc.2.20454.25
- Updates:
- Microsoft.EntityFrameworkCore.Tools: from 5.0.0-rc.2.20452.4 to 5.0.0-rc.2.20458.4
- Microsoft.EntityFrameworkCore.SqlServer: from 5.0.0-rc.2.20452.4 to 5.0.0-rc.2.20458.4
- dotnet-ef: from 5.0.0-rc.2.20452.4 to 5.0.0-rc.2.20458.4
- Microsoft.EntityFrameworkCore: from 5.0.0-rc.2.20452.4 to 5.0.0-rc.2.20458.4
- Microsoft.EntityFrameworkCore.Design: from 5.0.0-rc.2.20452.4 to 5.0.0-rc.2.20458.4
- Microsoft.EntityFrameworkCore.Relational: from 5.0.0-rc.2.20452.4 to 5.0.0-rc.2.20458.4
- Microsoft.EntityFrameworkCore.Sqlite: from 5.0.0-rc.2.20452.4 to 5.0.0-rc.2.20458.4
- Microsoft.EntityFrameworkCore.InMemory: from 5.0.0-rc.2.20452.4 to 5.0.0-rc.2.20458.4
- Updates:
- Microsoft.DotNet.Build.Tasks.Installers: from 5.0.0-beta.20431.1 to 5.0.0-beta.20452.19
- Microsoft.DotNet.Helix.Sdk: from 5.0.0-beta.20431.1 to 5.0.0-beta.20452.19
- Microsoft.DotNet.Arcade.Sdk: from 5.0.0-beta.20431.1 to 5.0.0-beta.20452.19
- System.IO.Pipelines Fix
(cherry picked from commit 520b9e23f027d7cca49d33f1dc6b2a0e57c893b3)
- Skip reference check of System.IO.Pipelines ref/ assembly
- add Framework projects to solution
- add Framework.slnf and startvs.cmd in src/Framework
- Merge branch 'release/5.0-rc2' into darc-release/5.0-rc2-d6b9c1c0-be36-4d12-b860-e7e54a75cb6d
- part of #24347
- unable to do src/Components/Authorization due to contained `*.razor` file
- ignored src/Components/Analyzers and src/Components/WebAssembly/Sdk
Doug Bunting
Pranav K
Matt Mitchell
Artak
Safia Abdalla
Javier Calvarro Nelson
dotnet-maestro[bot]
Steve Sanderson
Eric StJohn
Brennan
Hao Kung
John Luo
Mackinnon Buck