diff --git a/aspnetcore/breaking-changes/10/apidescription-client-deprecated.md b/aspnetcore/breaking-changes/10/apidescription-client-deprecated.md
new file mode 100644
index 000000000000..bd7df478d2d9
--- /dev/null
+++ b/aspnetcore/breaking-changes/10/apidescription-client-deprecated.md
@@ -0,0 +1,64 @@
+---
+title: "Breaking change - Microsoft.Extensions.ApiDescription.Client package deprecated"
+description: "Learn about the breaking change in ASP.NET Core 10 where the Microsoft.Extensions.ApiDescription.Client package has been deprecated."
+ms.date: 08/07/2025
+ai-usage: ai-assisted
+ms.custom: https://github.com/aspnet/Announcements/issues/518
+---
+
+# Microsoft.Extensions.ApiDescription.Client package deprecated
+
+The Microsoft.Extensions.ApiDescription.Client NuGet package has been deprecated. The package supplied MSBuild targets and CLI support that generated OpenAPI-based client code during the build. Projects that reference the package now receive a warning during build.
+
+## Version introduced
+
+.NET 10 Preview 7
+
+## Previous behavior
+
+Projects could add `` and `` items (or run `dotnet openapi`) to generate strongly typed clients at build time.
+
+```xml
+
+
+ net10.0
+
+
+
+
+
+
+
+
+
+
+```
+
+## New behavior
+
+The package is now deprecated and projects that reference it receive build warnings. The MSBuild targets and CLI commands are no longer supported.
+
+## Type of breaking change
+
+This change can affect [source compatibility](/dotnet/core/compatibility/categories#source-compatibility).
+
+## Reason for change
+
+- The package has seen minimal updates and maintenance since its introduction.
+- Its abstractions were tightly coupled to certain generators and did not scale well to others. Each generator now ships its own CLI/configuration experience, making the MSBuild middle-layer redundant.
+- Removing the package reduces maintenance burden and clarifies the recommended workflow for client generation.
+
+## Recommended action
+
+- Remove any `` from your project.
+- Replace `` items or `dotnet openapi` commands with generator-specific tooling:
+ - NSwag – Use `npx nswag` or `dotnet tool run nswag` with an `.nswag` config file.
+ - Kiota – Install with `dotnet tool install -g Microsoft.OpenApi.Kiota` and run `kiota generate`.
+ - OpenAPI generator – Invoke `openapi-generator-cli` via JAR or Docker.
+- Commit the generated client code or run generation in a custom pre-build step that doesn't rely on the removed package.
+
+## Affected APIs
+
+- MSBuild item `OpenApiReference` (all instances).
+- MSBuild property `OpenApiProjectReference`.
+- CLI command [`dotnet openapi`](/aspnet/core/fundamentals/openapi/openapi-tools).
diff --git a/aspnetcore/breaking-changes/10/cookie-authentication-api-endpoints.md b/aspnetcore/breaking-changes/10/cookie-authentication-api-endpoints.md
new file mode 100644
index 000000000000..aa6845a29862
--- /dev/null
+++ b/aspnetcore/breaking-changes/10/cookie-authentication-api-endpoints.md
@@ -0,0 +1,110 @@
+---
+title: "Cookie login redirects are disabled for known API endpoints"
+description: "Learn about the breaking change in ASP.NET Core 10 where cookie authentication no longer redirects to login or access denied URIs for known API endpoints."
+ms.date: 08/08/2025
+ai-usage: ai-assisted
+ms.custom: https://github.com/aspnet/Announcements/issues/525
+---
+
+# Cookie login redirects are disabled for known API endpoints
+
+By default, unauthenticated and unauthorized requests made to known API endpoints protected by cookie authentication now result in 401 and 403 responses rather than redirecting to a login or access-denied URI.
+
+Known API [endpoints](/aspnet/core/fundamentals/routing) are identified using the new `IApiEndpointMetadata` interface, and metadata implementing the new interface has been added automatically to the following:
+
+- [`[ApiController]`](xref:Microsoft.AspNetCore.Mvc.ApiControllerAttribute) endpoints.
+- Minimal API endpoints that read JSON request bodies or write JSON responses.
+- Endpoints using return types.
+- SignalR endpoints.
+
+## Version introduced
+
+.NET 10 Preview 7
+
+## Previous behavior
+
+Previously, the cookie authentication handler redirected unauthenticated and unauthorized requests to a login or access-denied URI by default for all requests other than [XMLHttpRequests (XHRs)](https://developer.mozilla.org/docs/Web/API/XMLHttpRequest).
+
+## New behavior
+
+Starting in .NET 10, unauthenticated and unauthorized requests made to known API endpoints result in 401 and 403 responses rather than redirecting to a login or access-denied URI. XHRs continue to result in 401 and 403 responses regardless of the target endpoint.
+
+## Type of breaking change
+
+This change is a [behavioral change](/dotnet/core/compatibility/categories#behavioral-change).
+
+## Reason for change
+
+This change was highly requested. Redirecting unauthenticated requests to a login page doesn't usually make sense for API endpoints, which typically rely on 401 and 403 status codes rather than HTML redirects to communicate auth failures.
+
+## Recommended action
+
+If you want to always redirect to the login and access-denied URIs for unauthenticated or unauthorized requests regardless of the target endpoint or whether the source of the request is an XHR, you can override and as follows:
+
+```csharp
+builder.Services.AddAuthentication()
+ .AddCookie(options =>
+ {
+ options.Events.OnRedirectToLogin = context =>
+ {
+ context.Response.Redirect(context.RedirectUri);
+ return Task.CompletedTask;
+ };
+
+ options.Events.OnRedirectToAccessDenied = context =>
+ {
+ context.Response.Redirect(context.RedirectUri);
+ return Task.CompletedTask;
+ };
+ });
+```
+
+If you want to revert to the exact previous behavior that avoids redirecting for only XHRs, you can override the events with this slightly more complicated logic:
+
+```csharp
+builder.Services.AddAuthentication()
+ .AddCookie(options =>
+ {
+ bool IsXhr(HttpRequest request)
+ {
+ return string.Equals(request.Query[HeaderNames.XRequestedWith], "XMLHttpRequest", StringComparison.Ordinal) ||
+ string.Equals(request.Headers.XRequestedWith, "XMLHttpRequest", StringComparison.Ordinal);
+ }
+
+ options.Events.OnRedirectToLogin = context =>
+ {
+ if (IsXhr(context.Request))
+ {
+ context.Response.Headers.Location = context.RedirectUri;
+ context.Response.StatusCode = 401;
+ }
+ else
+ {
+ context.Response.Redirect(context.RedirectUri);
+ }
+
+ return Task.CompletedTask;
+ };
+
+ options.Events.OnRedirectToAccessDenied = context =>
+ {
+ if (IsXhr(context.Request))
+ {
+ context.Response.Headers.Location = context.RedirectUri;
+ context.Response.StatusCode = 403;
+ }
+ else
+ {
+ context.Response.Redirect(context.RedirectUri);
+ }
+
+ return Task.CompletedTask;
+ };
+ });
+```
+
+## Affected APIs
+
+- `Microsoft.AspNetCore.Http.Metadata.IApiEndpointMetadata`
+-
+-
diff --git a/aspnetcore/breaking-changes/10/exception-handler-diagnostics-suppressed.md b/aspnetcore/breaking-changes/10/exception-handler-diagnostics-suppressed.md
new file mode 100644
index 000000000000..bdb26222bc3d
--- /dev/null
+++ b/aspnetcore/breaking-changes/10/exception-handler-diagnostics-suppressed.md
@@ -0,0 +1,56 @@
+---
+title: "Breaking change: Exception diagnostics are suppressed when IExceptionHandler.TryHandleAsync returns true"
+description: Learn about the breaking change in ASP.NET Core 10 where exception diagnostics are no longer recorded when IExceptionHandler.TryHandleAsync returns true.
+ms.date: 08/08/2025
+ms.custom: https://github.com/aspnet/Announcements/issues/524
+---
+
+# Exception diagnostics are suppressed when IExceptionHandler.TryHandleAsync returns true
+
+The ASP.NET Core exception handler middleware no longer records diagnostics for exceptions handled by by default.
+
+## Version introduced
+
+.NET 10 Preview 7
+
+## Previous behavior
+
+Previously, the exception handler middleware recorded diagnostics about exceptions handled by .
+
+The exception diagnostics are:
+
+- Logging `UnhandledException` to .
+- Writing the `Microsoft.AspNetCore.Diagnostics.HandledException` event to .
+- Adding the `error.type` tag to the `http.server.request.duration` metric.
+
+## New behavior
+
+Starting in .NET 10, if returns `true`, then exception diagnostics are no longer recorded by default.
+
+## Type of breaking change
+
+This change is a [behavioral change](/dotnet/core/compatibility/categories#behavioral-change).
+
+## Reason for change
+
+ASP.NET Core users have given feedback that the previous behavior was undesirable. Their implementation reported that the exception was handled, but the error handling middleware still recorded the error in the app's telemetry.
+
+ASP.NET Core now follows the behavior expected by users by suppressing diagnostics when handles the exception. Configuration options are also available to customize exception diagnostics behavior if needed.
+
+## Recommended action
+
+If you want handled exceptions to continue to record telemetry, you can use the new `ExceptionHandlerOptions.SuppressDiagnosticsCallback` option:
+
+```csharp
+app.UseExceptionHandler(new ExceptionHandlerOptions
+{
+ SuppressDiagnosticsCallback = context => false;
+});
+```
+
+The `context` passed to the callback includes information about the exception, the request, and whether the exception was handled. The callback returns `false` to indicate that diagnostics shouldn't be suppressed, thus restoring the previous behavior.
+
+## Affected APIs
+
+-
+-
diff --git a/aspnetcore/breaking-changes/10/iactioncontextaccessor-obsolete.md b/aspnetcore/breaking-changes/10/iactioncontextaccessor-obsolete.md
new file mode 100644
index 000000000000..6fc66f5a9295
--- /dev/null
+++ b/aspnetcore/breaking-changes/10/iactioncontextaccessor-obsolete.md
@@ -0,0 +1,104 @@
+---
+title: "IActionContextAccessor and ActionContextAccessor are obsolete"
+description: "Learn about the breaking change in ASP.NET Core 10 where IActionContextAccessor and ActionContextAccessor are marked as obsolete."
+ms.date: 08/07/2025
+ai-usage: ai-assisted
+ms.custom: https://github.com/aspnet/Announcements/issues/520
+---
+
+# IActionContextAccessor and ActionContextAccessor are obsolete
+
+ and have been marked as obsolete with diagnostic ID `ASPDEPR006`. With the introduction of endpoint routing, `IActionContextAccessor` is no longer necessary as developers can access action descriptor and metadata information directly through `HttpContext.GetEndpoint()`.
+
+## Version introduced
+
+.NET 10 Preview 7
+
+## Previous behavior
+
+Previously, you could use `IActionContextAccessor` to access the current :
+
+```csharp
+public class MyService
+{
+ private readonly IActionContextAccessor _actionContextAccessor;
+
+ public MyService(IActionContextAccessor actionContextAccessor)
+ {
+ _actionContextAccessor = actionContextAccessor;
+ }
+
+ public void DoSomething()
+ {
+ var actionContext = _actionContextAccessor.ActionContext;
+ var actionDescriptor = actionContext?.ActionDescriptor;
+ // Use action descriptor metadata.
+ }
+}
+```
+
+## New behavior
+
+Starting in .NET 10, using `IActionContextAccessor` and `ActionContextAccessor` produces a compiler warning with diagnostic ID `ASPDEPR006`:
+
+> warning ASPDEPR006: ActionContextAccessor is obsolete and will be removed in a future version. For more information, visit .
+
+## Type of breaking change
+
+This change can affect [source compatibility](/dotnet/core/compatibility/categories#source-compatibility).
+
+## Reason for change
+
+With the introduction of endpoint routing in ASP.NET Core, `IActionContextAccessor` is no longer necessary. The endpoint routing infrastructure provides a cleaner, more direct way to access endpoint metadata through `HttpContext.GetEndpoint()`, aligning with ASP.NET Core's architectural evolution toward endpoint routing.
+
+## Recommended action
+
+Migrate from `IActionContextAccessor` to and use `HttpContext.GetEndpoint()`:
+
+Before:
+
+```csharp
+public class MyService
+{
+ private readonly IActionContextAccessor _actionContextAccessor;
+
+ public MyService(IActionContextAccessor actionContextAccessor)
+ {
+ _actionContextAccessor = actionContextAccessor;
+ }
+
+ public void DoSomething()
+ {
+ var actionContext = _actionContextAccessor.ActionContext;
+ var actionDescriptor = actionContext?.ActionDescriptor;
+ // Use action descriptor metadata
+ }
+}
+```
+
+After:
+
+```csharp
+public class MyService
+{
+ private readonly IHttpContextAccessor _httpContextAccessor;
+
+ public MyService(IHttpContextAccessor httpContextAccessor)
+ {
+ _httpContextAccessor = httpContextAccessor;
+ }
+
+ public void DoSomething()
+ {
+ var httpContext = _httpContextAccessor.HttpContext;
+ var endpoint = httpContext?.GetEndpoint();
+ var actionDescriptor = endpoint?.Metadata.GetMetadata();
+ // Use action descriptor metadata.
+ }
+}
+```
+
+## Affected APIs
+
+-
+-
diff --git a/aspnetcore/breaking-changes/10/ipnetwork-knownnetworks-obsolete.md b/aspnetcore/breaking-changes/10/ipnetwork-knownnetworks-obsolete.md
new file mode 100644
index 000000000000..e57ecb5de760
--- /dev/null
+++ b/aspnetcore/breaking-changes/10/ipnetwork-knownnetworks-obsolete.md
@@ -0,0 +1,50 @@
+---
+title: "Breaking change: IPNetwork and ForwardedHeadersOptions.KnownNetworks are obsolete"
+description: Learn about the breaking change in ASP.NET Core 10.0 where IPNetwork and ForwardedHeadersOptions.KnownNetworks have been obsoleted in favor of System.Net.IPNetwork and KnownIPNetworks.
+ms.date: 08/08/2025
+ai-usage: ai-assisted
+ms.custom: https://github.com/aspnet/Announcements/issues/523
+---
+# IPNetwork and ForwardedHeadersOptions.KnownNetworks are obsolete
+
+ and have been marked as obsolete in favor of using and `KnownIPNetworks`.
+
+## Version introduced
+
+.NET 10 Preview 7
+
+## Previous behavior
+
+Previously, you could use and to configure known networks for the forwarded headers middleware:
+
+```csharp
+app.UseForwardedHeaders(new ForwardedHeadersOptions
+{
+ KnownNetworks.Add(new(IPAddress.Loopback, 8))
+});
+```
+
+## New behavior
+
+Starting in .NET 10, if you use [the obsolete APIs](#affected-apis) in your code, you'll get warning `ASPDEPR005` at compile time:
+
+> warning ASPDEPR005: Please use KnownIPNetworks instead. For more information, visit .
+
+Use the type and `KnownIPNetworks` property instead.
+
+## Type of breaking change
+
+This change can affect [source compatibility](/dotnet/core/compatibility/categories#source-compatibility).
+
+## Reason for change
+
+ has replaced the type that was implemented for .
+
+## Recommended action
+
+Change to using and `KnownIPNetworks`.
+
+## Affected APIs
+
+-
+-
diff --git a/aspnetcore/breaking-changes/10/openapi-analyzers-deprecated.md b/aspnetcore/breaking-changes/10/openapi-analyzers-deprecated.md
new file mode 100644
index 000000000000..38ff06def403
--- /dev/null
+++ b/aspnetcore/breaking-changes/10/openapi-analyzers-deprecated.md
@@ -0,0 +1,101 @@
+---
+title: "IncludeOpenAPIAnalyzers property and MVC API analyzers are deprecated"
+description: "Learn about the breaking change in ASP.NET Core 10 where the IncludeOpenAPIAnalyzers property and its associated MVC API analyzers are deprecated."
+ms.date: 08/07/2025
+ai-usage: ai-assisted
+ms.custom: https://github.com/aspnet/Announcements/issues/521
+---
+
+# IncludeOpenAPIAnalyzers property and MVC API analyzers are deprecated
+
+The `IncludeOpenAPIAnalyzers` MSBuild property and its associated MVC API analyzers are deprecated and will be removed in a future release. When `IncludeOpenAPIAnalyzers` is set to `true`, the build now emits warning `ASPDEPR007`.
+
+## Version introduced
+
+.NET 10 Preview 7
+
+## Previous behavior
+
+Previously, you could set `true` in your Web SDK projects to enable MVC API analyzers without any warnings or deprecation notices.
+
+```xml
+
+
+ net9.0
+ true
+
+
+```
+
+Such a project built successfully without any deprecation warnings.
+
+## New behavior
+
+Starting in .NET 10, when `IncludeOpenAPIAnalyzers` is set to `true`, the build emits warning `ASPDEPR007`:
+
+> warning ASPDEPR007: The IncludeOpenAPIAnalyzers property and its associated MVC API analyzers are deprecated and will be removed in a future release.
+
+The analyzers continue to function, but developers receive this deprecation warning during compilation.
+
+## Type of breaking change
+
+This change can affect [source compatibility](/dotnet/core/compatibility/categories#source-compatibility).
+
+## Reason for change
+
+The MVC API analyzers were originally introduced to help keep return types and attributes in sync for API controllers, ensuring consistency between method signatures and their corresponding OpenAPI documentation. These analyzers provided compile-time validation to catch mismatches between declared return types and the actual types returned by controller actions.
+
+However, with the introduction of Minimal APIs and the pattern, the .NET ecosystem has evolved toward a more type-safe approach for API development. `TypedResults` provides compile-time guarantees about response types without requiring additional analyzers, making the MVC API analyzers redundant for modern .NET applications. In .NET 10, `TypedResults` are supported in controller-based APIs.
+
+Previous approach with MVC API analyzers:
+
+```csharp
+[HttpGet]
+[ProducesResponseType(200)]
+[ProducesResponseType(404)]
+public async Task GetProduct(int id)
+{
+ var product = await _productService.GetByIdAsync(id);
+ if (product == null)
+ return NotFound(); // Analyzer ensures this matches ProducesResponseType(404)
+
+ return Ok(product); // Analyzer ensures this matches ProducesResponseType(200)
+}
+```
+
+Modern approach with `TypedResults`:
+
+```csharp
+[HttpGet("{id}")]
+public async Task, NotFound>> GetProduct(int id)
+{
+ var product = await _productService.GetByIdAsync(id);
+ return product == null
+ ? TypedResults.NotFound()
+ : TypedResults.Ok(product);
+}
+```
+
+The `TypedResults` pattern eliminates the need for separate analyzers because the return type itself (`Results, NotFound>`) explicitly declares all possible response types at compile time. This approach is more maintainable, provides better IntelliSense support, and automatically generates accurate OpenAPI documentation without additional tooling.
+
+As the .NET ecosystem continues to embrace `TypedResults` as the recommended pattern for API development, the MVC API analyzers have become obsolete and are being deprecated to streamline the development experience.
+
+## Recommended action
+
+Developers should:
+
+- Remove the deprecated property: Remove `true` from your project files to eliminate the warning.
+- Migrate to `TypedResults`: Migrate to the `TypedResults` pattern to ensure better consistency between application behavior and OpenAPI documentation.
+
+If you need to continue using the deprecated analyzers temporarily, you can suppress the warning:
+
+```xml
+
+ $(NoWarn);ASPDEPR007
+
+```
+
+## Affected APIs
+
+- MSBuild property: `IncludeOpenAPIAnalyzers`.
+- Associated MVC API analyzers included when `IncludeOpenAPIAnalyzers` is `true`.
diff --git a/aspnetcore/breaking-changes/10/overview.md b/aspnetcore/breaking-changes/10/overview.md
new file mode 100644
index 000000000000..89e4f67b36fd
--- /dev/null
+++ b/aspnetcore/breaking-changes/10/overview.md
@@ -0,0 +1,25 @@
+---
+title: Breaking changes in ASP.NET Core 10
+titleSuffix: ""
+description: Navigate to the breaking changes in ASP.NET Core 10.
+ms.date: 09/09/2025
+ai-usage: ai-assisted
+no-loc: [Razor]
+---
+# Breaking changes in ASP.NET Core 10
+
+If you're migrating an app to ASP.NET Core 10, the breaking changes listed here might affect you.
+
+[!INCLUDE [binary-source-behavioral](../includes/binary-source-behavioral.md)]
+
+| Title | Type of change |
+|-------|-------------------|
+| [Cookie login redirects disabled for known API endpoints](cookie-authentication-api-endpoints.md) | Behavioral change |
+| [Deprecation of WithOpenApi extension method](withopenapi-deprecated.md) | Source incompatible |
+| [Exception diagnostics suppressed when TryHandleAsync returns true](exception-handler-diagnostics-suppressed.md) | Behavioral change |
+| [IActionContextAccessor and ActionContextAccessor are obsolete](iactioncontextaccessor-obsolete.md) | Source incompatible/behavioral change |
+| [IncludeOpenAPIAnalyzers property and MVC API analyzers are deprecated](openapi-analyzers-deprecated.md) | Source incompatible |
+| [IPNetwork and ForwardedHeadersOptions.KnownNetworks are obsolete](ipnetwork-knownnetworks-obsolete.md) | Source incompatible |
+| [Microsoft.Extensions.ApiDescription.Client package deprecated](apidescription-client-deprecated.md) | Source incompatible |
+| [Razor runtime compilation is obsolete](razor-runtime-compilation-obsolete.md) | Source incompatible |
+| [WebHostBuilder, IWebHost, and WebHost are obsolete](webhostbuilder-deprecated.md) | Source incompatible |
diff --git a/aspnetcore/breaking-changes/10/razor-runtime-compilation-obsolete.md b/aspnetcore/breaking-changes/10/razor-runtime-compilation-obsolete.md
new file mode 100644
index 000000000000..3c9d8702df5d
--- /dev/null
+++ b/aspnetcore/breaking-changes/10/razor-runtime-compilation-obsolete.md
@@ -0,0 +1,48 @@
+---
+title: "Breaking change: Razor runtime compilation is obsolete"
+description: Learn about the breaking change in ASP.NET Core 10.0 where Razor runtime compilation APIs have been marked obsolete.
+ms.date: 08/08/2025
+ms.custom: https://github.com/aspnet/Announcements/issues/522
+---
+
+# Razor runtime compilation is obsolete
+
+Razor runtime compilation is obsolete and is not recommended for production scenarios. For production scenarios, use the default build-time compilation. For development scenarios, use [Hot Reload](/aspnet/core/test/hot-reload) instead.
+
+## Version introduced
+
+.NET 10 Preview 7
+
+## Previous behavior
+
+Previously, you could use [Razor runtime compilation](/aspnet/core/mvc/views/view-compilation) to recompile `.cshtml` files while the application was running. This meant you didn't need to restart the application for changes to take effect.
+
+## New behavior
+
+Starting in .NET 10, use of the [affected APIs](#affected-apis) produces a compiler warning with diagnostic ID `ASPDEPR003`:
+
+> warning ASPDEPR003: Razor runtime compilation is obsolete and is not recommended for production scenarios. For production scenarios, use the default build time compilation. For development scenarios, use Hot Reload instead. For more information, visit .
+
+## Type of breaking change
+
+This change can affect [source compatibility](/dotnet/core/compatibility/categories#source-compatibility).
+
+## Reason for change
+
+Razor runtime compilation has been replaced by [Hot Reload](/aspnet/core/test/hot-reload), which has been the recommended approach for a few years now. This change makes it clearer that Razor runtime compilation doesn't get support for new features and should no longer be used.
+
+## Recommended action
+
+Remove calls to and use [Hot Reload](/aspnet/core/test/hot-reload) instead.
+
+## Affected APIs
+
+-
+-
+-
+-
+-
+
+## See also
+
+- [.NET Hot Reload support for ASP.NET Core](/aspnet/core/test/hot-reload)
diff --git a/aspnetcore/breaking-changes/10/webhostbuilder-deprecated.md b/aspnetcore/breaking-changes/10/webhostbuilder-deprecated.md
new file mode 100644
index 000000000000..6cc1d4c536c8
--- /dev/null
+++ b/aspnetcore/breaking-changes/10/webhostbuilder-deprecated.md
@@ -0,0 +1,87 @@
+---
+title: "WebHostBuilder, IWebHost, and WebHost are obsolete"
+description: "Learn about the breaking change in ASP.NET Core 10 where WebHostBuilder, IWebHost, and WebHost are marked as obsolete."
+ms.date: 09/05/2025
+ai-usage: ai-generated
+ms.custom: https://github.com/aspnet/Announcements/issues/526
+---
+
+# WebHostBuilder, IWebHost, and WebHost are obsolete
+
+, , and have been marked as obsolete in .NET 10. `WebHostBuilder` was replaced by `HostBuilder` ([generic host](/aspnet/core/fundamentals/host/generic-host)) in ASP.NET Core 3.0, and `WebApplicationBuilder` was introduced in ASP.NET Core 6.0. These newer alternatives are where future investments will occur.
+
+## Version introduced
+
+.NET 10 RC 1
+
+## Previous behavior
+
+Previously, you could use `WebHostBuilder` to configure and build a web host without any compile-time warnings.
+
+## New behavior
+
+Starting in .NET 10, using `WebHostBuilder` produces a compiler warning with diagnostic ID `ASPDEPR004`:
+
+> warning ASPDEPR004: WebHostBuilder is deprecated in favor of HostBuilder and WebApplicationBuilder. For more information, visit .
+
+Using `IWebHost` or `WebHost` produces a compiler warning with diagnostic ID `ASPDEPR008`:
+
+> warning ASPDEPR008: WebHost is obsolete. Use HostBuilder or WebApplicationBuilder instead. For more information, visit .
+
+## Type of breaking change
+
+This change can affect [source compatibility](/dotnet/core/compatibility/categories#source-compatibility).
+
+## Reason for change
+
+`HostBuilder` and have all the features of `WebHostBuilder` and are the focus of future investment. `WebHostBuilder` was replaced by the generic host in ASP.NET Core 3.0, and minimal APIs with were introduced in ASP.NET Core 6.0. These newer hosting models provide better integration with the .NET ecosystem and are the recommended approach for new applications.
+
+## Recommended action
+
+Migrate from `WebHostBuilder` to either [`HostBuilder`](/aspnet/core/fundamentals/host/generic-host) or [`WebApplication`](/aspnet/core/fundamentals/minimal-apis/webapplication):
+
+- For applications that need the full hosting capabilities, migrate to `HostBuilder`:
+
+ **Before:**
+
+ ```csharp
+ var hostBuilder = new WebHostBuilder()
+ .UseContentRoot(Directory.GetCurrentDirectory())
+ .UseStartup()
+ .UseKestrel();
+ // Test code might use TestServer:
+ var testServer = new TestServer(hostBuilder);
+ ```
+
+ **After:**
+
+ ```csharp
+ using var host = new HostBuilder()
+ .ConfigureWebHost(webHostBuilder =>
+ {
+ webHostBuilder
+ .UseTestServer() // If using TestServer.
+ .UseContentRoot(Directory.GetCurrentDirectory())
+ .UseStartup()
+ .UseKestrel();
+ })
+ .Build();
+ await host.StartAsync();
+
+ var testServer = host.GetTestServer();
+ ```
+
+- For new applications, especially those using minimal APIs, migrate to .
+
+## Affected APIs
+
+-
+-
+-
+
+## See also
+
+- [Generic Host in ASP.NET Core](/aspnet/core/fundamentals/host/generic-host)
+- [Minimal APIs with WebApplication](/aspnet/core/fundamentals/minimal-apis/webapplication)
+- [HostBuilder replaces WebHostBuilder](/aspnet/core/migration/22-to-30#hostbuilder-replaces-webhostbuilder)
+- [Introducing WebApplication](/aspnet/core/migration/50-to-60#new-hosting-model)
diff --git a/aspnetcore/breaking-changes/10/withopenapi-deprecated.md b/aspnetcore/breaking-changes/10/withopenapi-deprecated.md
new file mode 100644
index 000000000000..f97fe2482d94
--- /dev/null
+++ b/aspnetcore/breaking-changes/10/withopenapi-deprecated.md
@@ -0,0 +1,98 @@
+---
+title: "Breaking change: Deprecation of WithOpenApi extension method"
+description: "Learn about the breaking change in ASP.NET Core 10 where WithOpenApi extension methods have been deprecated and produce a compiler warning."
+ms.date: 08/07/2025
+ai-usage: ai-assisted
+ms.custom: https://github.com/aspnet/Announcements/issues/519
+---
+
+# Deprecation of WithOpenApi extension method
+
+The methods have been deprecated in .NET 10. Invoking these methods now produces the compile-time diagnostic `ASPDEPR002` and a standard `Obsolete` warning that states:
+
+> WithOpenApi is deprecated and will be removed in a future release. For more information, visit .
+
+## Version introduced
+
+.NET 10 Preview 7
+
+## Previous behavior
+
+Previously, you could use the `WithOpenApi` extension method without any warnings:
+
+```csharp
+app.MapGet("/weather", () => ...)
+ .WithOpenApi(); // No warnings.
+```
+
+## New behavior
+
+Starting in .NET 10, using the `WithOpenApi` extension method produces a compiler warning:
+
+```csharp
+app.MapGet("/weather", () => ...)
+ .WithOpenApi(); // Warning ASPDEPR002: WithOpenApi is deprecated...
+```
+
+However, the call still compiles and executes.
+
+## Type of breaking change
+
+This change can affect [source compatibility](/dotnet/core/compatibility/categories#source-compatibility).
+
+## Reason for change
+
+ duplicated functionality now provided by the built-in OpenAPI document generation pipeline. Deprecating it simplifies the API surface and prepares for its eventual removal.
+
+## Recommended action
+
+Remove `.WithOpenApi()` calls from your code.
+
+- If you used `Microsoft.AspNetCore.OpenApi` for document generation, use the extension method.
+
+ Before:
+
+ ```csharp
+ using Microsoft.AspNetCore.OpenApi;
+
+ var builder = WebApplication.CreateBuilder();
+ var app = builder.Build();
+
+ app.MapGet("/weather", () => ...)
+ .WithOpenApi(operation =>
+ {
+ // Per-endpoint tweaks
+ operation.Summary = "Gets the current weather report.";
+ operation.Description = "Returns a short description and emoji.";
+ return operation;
+ });
+
+ app.Run();
+ ```
+
+ After:
+
+ ```csharp
+ using Microsoft.AspNetCore.OpenApi;
+
+ var builder = WebApplication.CreateBuilder();
+ var app = builder.Build();
+
+ app.MapGet("/weather", () => ...)
+ .AddOpenApiOperationTransformer((operation, context, ct) =>
+ {
+ // Per-endpoint tweaks
+ operation.Summary = "Gets the current weather report.";
+ operation.Description = "Returns a short description and emoji.";
+ return Task.CompletedTask;
+ });
+
+ app.Run();
+ ```
+
+- If you used `Swashbuckle` for document generation, use the `IOperationFilter` API.
+- If you used `NSwag` for document generation, use the `IOperationProcessor` API.
+
+## Affected APIs
+
+-
diff --git a/aspnetcore/breaking-changes/5/authentication-aad-packages-obsolete.md b/aspnetcore/breaking-changes/5/authentication-aad-packages-obsolete.md
new file mode 100644
index 000000000000..7debd2cbd7c0
--- /dev/null
+++ b/aspnetcore/breaking-changes/5/authentication-aad-packages-obsolete.md
@@ -0,0 +1,60 @@
+---
+title: "Breaking change: Authentication: AzureAD.UI and AzureADB2C.UI APIs and packages marked obsolete"
+description: "Learn about the breaking change in ASP.NET Core 5.0 titled Authentication: AzureAD.UI and AzureADB2C.UI APIs and packages marked obsolete"
+ms.author: scaddie
+ms.date: 10/01/2020
+ms.custom: https://github.com/aspnet/Announcements/issues/439
+---
+# Authentication: AzureAD.UI and AzureADB2C.UI APIs and packages marked obsolete
+
+In ASP.NET Core 2.1, integration with Azure Active Directory (Azure AD) and Azure Active Directory B2C (Azure AD B2C) authentication is provided by the [Microsoft.AspNetCore.Authentication.AzureAD.UI](https://www.nuget.org/packages/Microsoft.AspNetCore.Authentication.AzureAD.UI) and [Microsoft.AspNetCore.Authentication.AzureADB2C.UI](https://www.nuget.org/packages/Microsoft.AspNetCore.Authentication.AzureADB2C.UI) packages. The functionality provided by these packages is based on the Azure AD v1.0 endpoint.
+
+In ASP.NET Core 5.0 and later, integration with Azure AD and Azure AD B2C authentication is provided by the [Microsoft.Identity.Web](https://www.nuget.org/packages/Microsoft.Identity.Web) package. This package is based on the Microsoft Identity Platform, which is formerly known as the Azure AD v2.0 endpoint. Consequently, the old APIs in the `Microsoft.AspNetCore.Authentication.AzureAD.UI` and `Microsoft.AspNetCore.Authentication.AzureADB2C.UI` packages were deprecated.
+
+For discussion, see GitHub issue [dotnet/aspnetcore#25807](https://github.com/dotnet/aspnetcore/issues/25807).
+
+## Version introduced
+
+5.0 Preview 8
+
+## Old behavior
+
+The APIs weren't marked as obsolete.
+
+## New behavior
+
+The APIs are marked as obsolete.
+
+## Reason for change
+
+The Azure AD and Azure AD B2C authentication functionality was migrated to Microsoft Authentication Library (MSAL) APIs that are provided by `Microsoft.Identity.Web`.
+
+## Recommended action
+
+Follow the `Microsoft.Identity.Web` API guidance for [web apps](https://github.com/azuread/microsoft-identity-web/wiki/web-apps) and [web APIs](https://github.com/azuread/microsoft-identity-web/wiki/web-apis).
+
+## Affected APIs
+
+* [Microsoft.AspNetCore.Authentication.AzureADAuthenticationBuilderExtensions](/dotnet/api/microsoft.aspnetcore.authentication.azureadauthenticationbuilderextensions?view=aspnetcore-3.0&preserve-view=false)
+* [Microsoft.AspNetCore.Authentication.AzureAD.UI.AzureADDefaults](/dotnet/api/microsoft.aspnetcore.authentication.azuread.ui.azureaddefaults?view=aspnetcore-3.0&preserve-view=false)
+* [Microsoft.AspNetCore.Authentication.AzureAD.UI.AzureADOptions](/dotnet/api/microsoft.aspnetcore.authentication.azuread.ui.azureadoptions?view=aspnetcore-3.0&preserve-view=false)
+* [Microsoft.AspNetCore.Authentication.AzureADB2CAuthenticationBuilderExtensions](/dotnet/api/microsoft.aspnetcore.authentication.azureadb2cauthenticationbuilderextensions?view=aspnetcore-3.0&preserve-view=false)
+* [Microsoft.AspNetCore.Authentication.AzureADB2C.UI.AzureADB2CDefaults](/dotnet/api/microsoft.aspnetcore.authentication.azureadb2c.ui.azureadb2cdefaults?view=aspnetcore-3.0&preserve-view=false)
+* [Microsoft.AspNetCore.Authentication.AzureADB2C.UI.AzureADB2COptions](/dotnet/api/microsoft.aspnetcore.authentication.azureadb2c.ui.azureadb2coptions?view=aspnetcore-3.0&preserve-view=false)
+
+
diff --git a/aspnetcore/breaking-changes/5/authorization-resource-in-endpoint-routing.md b/aspnetcore/breaking-changes/5/authorization-resource-in-endpoint-routing.md
new file mode 100644
index 000000000000..244638f6f443
--- /dev/null
+++ b/aspnetcore/breaking-changes/5/authorization-resource-in-endpoint-routing.md
@@ -0,0 +1,54 @@
+---
+title: "Breaking change: Authorization: Resource in endpoint routing is HttpContext"
+description: "Learn about the breaking change in ASP.NET Core 5.0 titled Authorization: Resource in endpoint routing is HttpContext"
+ms.author: scaddie
+ms.date: 10/01/2020
+ms.custom: https://github.com/aspnet/Announcements/issues/423
+---
+# Authorization: Resource in endpoint routing is HttpContext
+
+When using endpoint routing in ASP.NET Core 3.1, the resource used for authorization is the endpoint. This approach was insufficient for gaining access to the route data (). Previously in MVC, an resource was passed in, which allows access to both the endpoint () and the route data. This change ensures that the resource passed to authorization is always the `HttpContext`.
+
+## Version introduced
+
+ASP.NET Core 5.0
+
+## Old behavior
+
+When using endpoint routing and the authorization middleware () or [[Authorize]](xref:Microsoft.AspNetCore.Authorization.AuthorizeAttribute) attributes, the resource passed to authorization is the matching endpoint.
+
+## New behavior
+
+Endpoint routing passes the `HttpContext` to authorization.
+
+## Reason for change
+
+You can get to the endpoint from the `HttpContext`. However, there was no way to get from the endpoint to things like the route data. There was a loss in functionality from non-endpoint routing.
+
+## Recommended action
+
+If your app uses the endpoint resource, call on the `HttpContext` to continue accessing the endpoint.
+
+You can revert to the old behavior with . For example:
+
+```csharp
+AppContext.SetSwitch(
+ "Microsoft.AspNetCore.Authorization.SuppressUseHttpContextAsAuthorizationResource",
+ isEnabled: true);
+```
+
+## Affected APIs
+
+None
+
+
diff --git a/aspnetcore/breaking-changes/5/azure-integration-packages-removed.md b/aspnetcore/breaking-changes/5/azure-integration-packages-removed.md
new file mode 100644
index 000000000000..003a2182f7c9
--- /dev/null
+++ b/aspnetcore/breaking-changes/5/azure-integration-packages-removed.md
@@ -0,0 +1,74 @@
+---
+title: "Breaking change: Azure: Microsoft-prefixed Azure integration packages removed"
+description: "Learn about the breaking change in ASP.NET Core 5.0 titled Azure: Microsoft-prefixed Azure integration packages removed"
+ms.author: scaddie
+ms.date: 10/01/2020
+ms.custom: https://github.com/aspnet/Announcements/issues/408
+---
+# Azure: Microsoft-prefixed Azure integration packages removed
+
+The following `Microsoft.*` packages that provide integration between ASP.NET Core and Azure SDKs aren't included in ASP.NET Core 5.0:
+
+* [Microsoft.Extensions.Configuration.AzureKeyVault](https://www.nuget.org/packages/Microsoft.Extensions.Configuration.AzureKeyVault/), which integrates [Azure Key Vault](/azure/key-vault/) into the [Configuration system](/aspnet/core/fundamentals/configuration/).
+* [Microsoft.AspNetCore.DataProtection.AzureKeyVault](https://www.nuget.org/packages/Microsoft.AspNetCore.DataProtection.AzureKeyVault/), which integrates Azure Key Vault into the [ASP.NET Core Data Protection system](/aspnet/core/security/data-protection/introduction).
+* [Microsoft.AspNetCore.DataProtection.AzureStorage](https://www.nuget.org/packages/Microsoft.AspNetCore.DataProtection.AzureStorage/), which integrates [Azure Blob Storage](/azure/storage/blobs/) into the ASP.NET Core Data Protection system.
+
+For discussion on this issue, see [dotnet/aspnetcore#19570](https://github.com/dotnet/aspnetcore/issues/19570).
+
+## Version introduced
+
+5.0 Preview 1
+
+## Old behavior
+
+The `Microsoft.*` packages integrated Azure services with the Configuration and Data Protection APIs.
+
+## New behavior
+
+New `Azure.*` packages integrate Azure services with the Configuration and Data Protection APIs.
+
+## Reason for change
+
+The change was made because the `Microsoft.*` packages were:
+
+* Using outdated versions of the Azure SDK. Simple updates weren't possible because the new versions of the Azure SDK included breaking changes.
+* Tied to the .NET Core release schedule. Transferring ownership of the packages to the Azure SDK team enables package updates as the Azure SDK is updated.
+
+## Recommended action
+
+In ASP.NET Core 2.1 or later projects, replace the old `Microsoft.*` with the new `Azure.*` packages.
+
+| Old | New |
+|--|--|
+| `Microsoft.AspNetCore.DataProtection.AzureKeyVault` | [Azure.Extensions.AspNetCore.DataProtection.Keys](https://www.nuget.org/packages/Azure.Extensions.AspNetCore.DataProtection.Keys) |
+| `Microsoft.AspNetCore.DataProtection.AzureStorage` | [Azure.Extensions.AspNetCore.DataProtection.Blobs](https://www.nuget.org/packages/Azure.Extensions.AspNetCore.DataProtection.Blobs) |
+| `Microsoft.Extensions.Configuration.AzureKeyVault` | [Azure.Extensions.AspNetCore.Configuration.Secrets](https://www.nuget.org/packages/Azure.Extensions.AspNetCore.Configuration.Secrets) |
+
+The new packages use a new version of the Azure SDK that includes breaking changes. The general usage patterns are unchanged. Some overloads and options may differ to adapt to changes in the underlying Azure SDK APIs.
+
+The old packages will:
+
+* Be supported by the ASP.NET Core team for the lifetime of .NET Core 2.1 and 3.1.
+* Not be included in .NET 5.
+
+When upgrading your project to .NET 5, transition to the `Azure.*` packages to maintain support.
+
+## Affected APIs
+
+-
+-
+-
+
+
diff --git a/aspnetcore/breaking-changes/5/blazor-browser-support-updated.md b/aspnetcore/breaking-changes/5/blazor-browser-support-updated.md
new file mode 100644
index 000000000000..8bb7a391303d
--- /dev/null
+++ b/aspnetcore/breaking-changes/5/blazor-browser-support-updated.md
@@ -0,0 +1,52 @@
+---
+title: "Breaking change: Blazor: Updated browser support"
+description: "Learn about the breaking change in ASP.NET Core 5.0 titled Blazor: Updated browser support"
+ms.author: scaddie
+ms.date: 10/01/2020
+ms.custom: https://github.com/aspnet/Announcements/issues/441
+no-loc: [Blazor, "Blazor WebAssembly", "Blazor Server"]
+---
+# Blazor: Updated browser support
+
+ASP.NET Core 5.0 introduces [new Blazor features](https://github.com/dotnet/aspnetcore/issues/21514), some of which are incompatible with older browsers. The list of browsers supported by Blazor in ASP.NET Core 5.0 has been updated accordingly.
+
+For discussion, see GitHub issue [dotnet/aspnetcore#26475](https://github.com/dotnet/aspnetcore/issues/26475).
+
+## Version introduced
+
+5.0
+
+## Old behavior
+
+Blazor Server supports Microsoft Internet Explorer 11 with sufficient polyfills. Blazor Server and Blazor WebAssembly are also functional in [Microsoft Edge Legacy](https://support.microsoft.com/help/4533505/what-is-microsoft-edge-legacy).
+
+## New behavior
+
+Blazor Server in ASP.NET Core 5.0 isn't supported with Microsoft Internet Explorer 11. Blazor Server and Blazor WebAssembly aren't fully functional in Microsoft Edge Legacy.
+
+## Reason for change
+
+New Blazor features in ASP.NET Core 5.0 are incompatible with these older browsers, and use of these older browsers is diminishing. For more information, see the following resources:
+
+* [Windows support for Microsoft Edge Legacy is also ending on March 9, 2021](https://support.microsoft.com/help/4533505/what-is-microsoft-edge-legacy)
+* [Microsoft 365 apps and services will end support for Microsoft Internet Explorer 11 by August 17, 2021](/lifecycle/announcements/m365-ie11-microsoft-edge-legacy)
+
+## Recommended action
+
+Upgrade from these older browsers to the [new, Chromium-based Microsoft Edge](https://www.microsoft.com/edge). For Blazor apps that need to support these older browsers, use ASP.NET Core 3.1. The supported browsers list for Blazor in ASP.NET Core 3.1 hasn't changed and is documented at [Supported platforms](/aspnet/core/blazor/supported-platforms?view=aspnetcore-3.1&preserve-view=true).
+
+## Affected APIs
+
+None
+
+
diff --git a/aspnetcore/breaking-changes/5/blazor-components-trim-insignificant-whitespace.md b/aspnetcore/breaking-changes/5/blazor-components-trim-insignificant-whitespace.md
new file mode 100644
index 000000000000..1250ff834e4f
--- /dev/null
+++ b/aspnetcore/breaking-changes/5/blazor-components-trim-insignificant-whitespace.md
@@ -0,0 +1,88 @@
+---
+title: "Breaking change: Blazor: Insignificant whitespace trimmed from components at compile time"
+description: "Learn about the breaking change in ASP.NET Core 5.0 titled Blazor: Insignificant whitespace trimmed from components at compile time"
+ms.author: scaddie
+ms.date: 10/01/2020
+ms.custom: https://github.com/aspnet/Announcements/issues/426
+---
+# Blazor: Insignificant whitespace trimmed from components at compile time
+
+Starting with ASP.NET Core 5.0, the Razor compiler omits insignificant whitespace in Razor components (*.razor* files) at compile time. For discussion, see issue [dotnet/aspnetcore#23568](https://github.com/dotnet/aspnetcore/issues/23568).
+
+## Version introduced
+
+5.0
+
+## Old behavior
+
+In 3.x versions of Blazor Server and Blazor WebAssembly, whitespace is honored in a component's source code. Whitespace-only text nodes render in the browser's Document Object Model (DOM) even when there's no visual effect.
+
+Consider the following Razor component code:
+
+```razor
+
+ @foreach (var item in Items)
+ {
+ -
+ @item.Text
+
+ }
+
+```
+
+The preceding example renders two whitespace nodes:
+
+* Outside of the `@foreach` code block.
+* Around the `` element.
+* Around the `@item.Text` output.
+
+A list containing 100 items results in 402 whitespace nodes. That's over half of all nodes rendered, even though none of the whitespace nodes visually affect the rendered output.
+
+When rendering static HTML for components, whitespace inside a tag wasn't preserved. For example, view the source of the following component:
+
+```razor
+
+```
+
+Whitespace isn't preserved. The pre-rendered output is:
+
+```razor
+
+```
+
+## New behavior
+
+Unless the `@preservewhitespace` directive is used with value `true`, whitespace nodes are removed if they:
+
+* Are leading or trailing within an element.
+* Are leading or trailing within a `RenderFragment` parameter. For example, child content being passed to another component.
+* Precede or follow a C# code block such as `@if` and `@foreach`.
+
+## Reason for change
+
+A goal for Blazor in ASP.NET Core 5.0 is to improve the performance of rendering and diffing. Insignificant whitespace tree nodes consumed up to 40 percent of the rendering time in benchmarks.
+
+## Recommended action
+
+In most cases, the visual layout of the rendered component is unaffected. However, the whitespace removal might affect the rendered output when using a CSS rule like `white-space: pre`. To disable this performance optimization and preserve the whitespace, take one of the following actions:
+
+* Add the `@preservewhitespace true` directive at the top of the *.razor* file to apply the preference to a specific component.
+* Add the `@preservewhitespace true` directive inside an *_Imports.razor* file to apply the preference to an entire subdirectory or the entire project.
+
+In most cases, no action is required, as applications will typically continue to behave normally (but faster). If the whitespace stripping causes any problems for a particular component, use `@preservewhitespace true` in that component to disable this optimization.
+
+## Affected APIs
+
+None
+
+
diff --git a/aspnetcore/breaking-changes/5/blazor-jsobjectreference-to-internal.md b/aspnetcore/breaking-changes/5/blazor-jsobjectreference-to-internal.md
new file mode 100644
index 000000000000..a4c4b3ef70ae
--- /dev/null
+++ b/aspnetcore/breaking-changes/5/blazor-jsobjectreference-to-internal.md
@@ -0,0 +1,58 @@
+---
+title: "Breaking change: Blazor: JSObjectReference and JSInProcessObjectReference types changed to internal"
+description: "Learn about the breaking change in ASP.NET Core 5.0 titled Blazor: JSObjectReference and JSInProcessObjectReference types changed to internal"
+ms.author: scaddie
+ms.date: 10/01/2020
+ms.custom: https://github.com/aspnet/Announcements/issues/435
+---
+# Blazor: JSObjectReference and JSInProcessObjectReference types changed to internal
+
+The new `Microsoft.JSInterop.JSObjectReference` and `Microsoft.JSInterop.JSInProcessObjectReference` types introduced in ASP.NET Core 5.0 RC1 have been marked as `internal`.
+
+## Version introduced
+
+5.0 RC2
+
+## Old behavior
+
+A `JSObjectReference` can be obtained from a JavaScript interop call via `IJSRuntime`. For example:
+
+```csharp
+var jsObjectReference = await JSRuntime.InvokeAsync(...);
+```
+
+## New behavior
+
+`JSObjectReference` uses the [internal](/dotnet/csharp/language-reference/keywords/internal) access modifier. The `public` `IJSObjectReference` interface must be used instead. For example:
+
+```csharp
+var jsObjectReference = await JSRuntime.InvokeAsync(...);
+```
+
+`JSInProcessObjectReference` was also marked as `internal` and was replaced by `IJSInProcessObjectReference`.
+
+## Reason for change
+
+The change makes the JavaScript interop feature more consistent with other patterns within Blazor. `IJSObjectReference` is analogous to `IJSRuntime` in that it serves a similar purpose and has similar methods and extensions.
+
+## Recommended action
+
+Replace occurrences of `JSObjectReference` and `JSInProcessObjectReference` with `IJSObjectReference` and `IJSInProcessObjectReference`, respectively.
+
+## Affected APIs
+
+- `Microsoft.JSInterop.JSObjectReference`
+- `Microsoft.JSInterop.JSInProcessObjectReference`
+
+
diff --git a/aspnetcore/breaking-changes/5/blazor-packages-target-framework-changed.md b/aspnetcore/breaking-changes/5/blazor-packages-target-framework-changed.md
new file mode 100644
index 000000000000..e93b6b10461a
--- /dev/null
+++ b/aspnetcore/breaking-changes/5/blazor-packages-target-framework-changed.md
@@ -0,0 +1,58 @@
+---
+title: "Breaking change: Blazor: Target framework of NuGet packages changed"
+description: "Learn about the breaking change in ASP.NET Core 5.0 titled Blazor: Target framework of NuGet packages changed"
+ms.author: scaddie
+ms.date: 10/01/2020
+ms.custom: https://github.com/aspnet/Announcements/issues/425
+---
+# Blazor: Target framework of NuGet packages changed
+
+Blazor 3.2 WebAssembly projects were compiled to target .NET Standard 2.1 (`netstandard2.1`). In ASP.NET Core 5.0, both Blazor Server and Blazor WebAssembly projects target .NET 5 (`net5.0`). To better align with the target framework change, the following Blazor packages no longer target .NET Standard 2.1:
+
+* [Microsoft.AspNetCore.Components](https://www.nuget.org/packages/Microsoft.AspNetCore.Components)
+* [Microsoft.AspNetCore.Components.Authorization](https://www.nuget.org/packages/Microsoft.AspNetCore.Components.Authorization)
+* [Microsoft.AspNetCore.Components.Forms](https://www.nuget.org/packages/Microsoft.AspNetCore.Components.Forms)
+* [Microsoft.AspNetCore.Components.Web](https://www.nuget.org/packages/Microsoft.AspNetCore.Components.Web)
+* [Microsoft.AspNetCore.Components.WebAssembly](https://www.nuget.org/packages/Microsoft.AspNetCore.Components.WebAssembly)
+* [Microsoft.AspNetCore.Components.WebAssembly.Authentication](https://www.nuget.org/packages/Microsoft.AspNetCore.Components.WebAssembly.Authentication)
+* [Microsoft.JSInterop](https://www.nuget.org/packages/Microsoft.JSInterop)
+* [Microsoft.JSInterop.WebAssembly](https://www.nuget.org/packages/Microsoft.JSInterop.WebAssembly)
+* [Microsoft.Authentication.WebAssembly.Msal](https://www.nuget.org/packages/Microsoft.Authentication.WebAssembly.Msal)
+
+For discussion, see GitHub issue [dotnet/aspnetcore#23424](https://github.com/dotnet/aspnetcore/issues/23424).
+
+## Version introduced
+
+5.0 Preview 7
+
+## Old behavior
+
+In Blazor 3.1 and 3.2, packages target .NET Standard 2.1 and .NET Core 3.1.
+
+## New behavior
+
+In ASP.NET Core 5.0, packages target .NET 5.0.
+
+## Reason for change
+
+The change was made to better align with .NET target framework requirements.
+
+## Recommended action
+
+Blazor 3.2 WebAssembly projects should target .NET 5 as part of updating their package references to 5.x.x. Libraries that reference one of these packages can either target .NET 5 or multi-target depending on their requirements.
+
+## Affected APIs
+
+None
+
+
diff --git a/aspnetcore/breaking-changes/5/blazor-protectedbrowserstorage-moved.md b/aspnetcore/breaking-changes/5/blazor-protectedbrowserstorage-moved.md
new file mode 100644
index 000000000000..cb35950ec378
--- /dev/null
+++ b/aspnetcore/breaking-changes/5/blazor-protectedbrowserstorage-moved.md
@@ -0,0 +1,58 @@
+---
+title: "Breaking change: Blazor: ProtectedBrowserStorage feature moved to shared framework"
+description: "Learn about the breaking change in ASP.NET Core 5.0 titled Blazor: ProtectedBrowserStorage feature moved to shared framework"
+ms.author: scaddie
+ms.date: 10/01/2020
+ms.custom: https://github.com/aspnet/Announcements/issues/436
+---
+# Blazor: ProtectedBrowserStorage feature moved to shared framework
+
+As part of the ASP.NET Core 5.0 RC2 release, the `ProtectedBrowserStorage` feature moved to the ASP.NET Core shared framework.
+
+## Version introduced
+
+5.0 RC2
+
+## Old behavior
+
+In ASP.NET Core 5.0 Preview 8, the feature is available as a part of the [Microsoft.AspNetCore.Components.Web.Extensions](https://www.nuget.org/packages/Microsoft.AspNetCore.Components.Web.Extensions) package but was only usable in Blazor WebAssembly.
+
+In ASP.NET Core 5.0 RC1, the feature is available as part of the [Microsoft.AspNetCore.Components.ProtectedBrowserStorage](https://www.nuget.org/packages/Microsoft.AspNetCore.Components.ProtectedBrowserStorage) package, which references the `Microsoft.AspNetCore.App` shared framework.
+
+## New behavior
+
+In ASP.NET Core 5.0 RC2, a NuGet package reference is no longer needed to reference and use the feature.
+
+## Reason for change
+
+The move to the shared framework is a better fit for the user experience customers expect.
+
+## Recommended action
+
+If upgrading from ASP.NET Core 5.0 RC1, complete the following steps:
+
+1. Remove the `Microsoft.AspNetCore.Components.ProtectedBrowserStorage` package reference from the project.
+1. Replace `using Microsoft.AspNetCore.Components.ProtectedBrowserStorage;` with `using Microsoft.AspNetCore.Components.Server.ProtectedBrowserStorage;`.
+1. Remove the call to `AddProtectedBrowserStorage` from your `Startup` class.
+
+If upgrading from ASP.NET Core 5.0 Preview 8, complete the following steps:
+
+1. Remove the `Microsoft.AspNetCore.Components.Web.Extensions` package reference from the project.
+1. Replace `using Microsoft.AspNetCore.Components.Web.Extensions;` with `using Microsoft.AspNetCore.Components.Server.ProtectedBrowserStorage;`.
+1. Remove the call to `AddProtectedBrowserStorage` from your `Startup` class.
+
+## Affected APIs
+
+None
+
+
diff --git a/aspnetcore/breaking-changes/5/blazor-rendertreeframe-fields-become-properties.md b/aspnetcore/breaking-changes/5/blazor-rendertreeframe-fields-become-properties.md
new file mode 100644
index 000000000000..5be08fef2801
--- /dev/null
+++ b/aspnetcore/breaking-changes/5/blazor-rendertreeframe-fields-become-properties.md
@@ -0,0 +1,71 @@
+---
+title: "Breaking change: Blazor: RenderTreeFrame readonly public fields have become properties"
+description: "Learn about the breaking change in ASP.NET Core 5.0 titled Blazor: RenderTreeFrame readonly public fields have become properties"
+ms.author: scaddie
+ms.date: 10/01/2020
+ms.custom: https://github.com/aspnet/Announcements/issues/438
+---
+# Blazor: RenderTreeFrame readonly public fields have become properties
+
+In ASP.NET Core 3.0 and 3.1, the struct exposed various `readonly public` fields, including , , and others. In ASP.NET Core 5.0 RC1 and later versions, all the `readonly public` fields changed to `readonly public` properties.
+
+This change won't affect many developers because:
+
+* Any app or library that simply uses `.razor` files (or even manual calls) to define its components wouldn't be referencing this type directly.
+* The `RenderTreeFrame` type itself is regarded as an implementation detail, not intended for use outside of the framework. ASP.NET Core 3.0 and later includes an analyzer that issues compiler warnings if the type is being used directly.
+* Even if you reference `RenderTreeFrame` directly, this change is binary-breaking but not source-breaking. That is, your existing source code will compile and behave properly. You'll only encounter an issue if compiling against a .NET Core 3.x framework and then running those binaries against the .NET 5 or a later framework.
+
+For discussion, see GitHub issue [dotnet/aspnetcore#25727](https://github.com/dotnet/aspnetcore/issues/25727).
+
+## Version introduced
+
+5.0 RC1
+
+## Old behavior
+
+Public members on `RenderTreeFrame` are defined as fields. For example, `renderTreeFrame.Sequence` and `renderTreeFrame.ElementName`.
+
+## New behavior
+
+Public members on `RenderTreeFrame` are defined as properties with the same names as before. For example, `renderTreeFrame.Sequence` and `renderTreeFrame.ElementName`.
+
+If older precompiled code hasn't been recompiled since this change, it may throw an exception similar to *MissingFieldException: Field not found: 'Microsoft.AspNetCore.Components.RenderTree.RenderTreeFrame.FrameType'*.
+
+## Reason for change
+
+This change was necessary to implement high-impact performance improvements in Razor component rendering in ASP.NET Core 5.0. The same levels of safety and encapsulation are maintained.
+
+## Recommended action
+
+Most Blazor developers are unaffected by this change. The change is more likely to affect library and package authors, but only in rare cases. Specifically, if you're developing:
+
+* An app and using ASP.NET Core 3.x or upgrading to 5.0 RC1 or later, you don't need to change your own code. However, if you depend on a library that upgraded to account for this change, then you need to update to a newer version of that library.
+* A library and want to support only ASP.NET Core 5.0 RC1 or later, no action is needed. Just ensure that your project file declares a `` value of `net5.0` or a later version.
+* A library and want to support both ASP.NET Core 3.x *and* 5.0, determine whether your code reads any `RenderTreeFrame` members. For example, evaluating `someRenderTreeFrame.FrameType`.
+ * Most libraries won't read `RenderTreeFrame` members, including libraries that contain `.razor` components. In this case, no action is needed.
+ * However, if your library does that, you'll need to multi-target to support both `netstandard2.1` and `net5.0`. Apply the following changes in your project file:
+ * Replace the existing `` element with `netstandard2.0;net5.0`.
+ * Use a conditional `Microsoft.AspNetCore.Components` package reference to account for both versions you wish to support. For example:
+
+ ```xml
+
+
+ ```
+
+For further clarification, see this [diff showing how @jsakamoto already upgraded the `Toolbelt.Blazor.HeadElement` library](https://github.com/jsakamoto/Toolbelt.Blazor.HeadElement/commit/090df430ba725f9420d412753db8104e8c32bf51).
+
+## Affected APIs
+
+
+
+
diff --git a/aspnetcore/breaking-changes/5/blazor-routing-logic-changed.md b/aspnetcore/breaking-changes/5/blazor-routing-logic-changed.md
new file mode 100644
index 000000000000..15365a2008b4
--- /dev/null
+++ b/aspnetcore/breaking-changes/5/blazor-routing-logic-changed.md
@@ -0,0 +1,52 @@
+---
+title: "Breaking change: Blazor: Changes to routing logic in Blazor apps"
+description: "Learn about the breaking change in ASP.NET Core 5.0 titled Blazor: Changes to routing logic in Blazor apps"
+ms.author: scaddie
+ms.date: 12/14/2020
+ms.custom: https://github.com/aspnet/Announcements/issues/445
+---
+# Blazor: Route precedence logic changed in Blazor apps
+
+A bug in the Blazor routing implementation affected how the precedence of routes was determined. This bug affects catch-all routes or routes with optional parameters within your Blazor app.
+
+## Version introduced
+
+5.0.1
+
+## Old behavior
+
+With the erroneous behavior, routes with lower precedence are considered and matched over routes with higher precedence. For example, the `{*slug}` route is matched before `/customer/{id}`.
+
+## New behavior
+
+The current behavior more closely matches the routing behavior defined in ASP.NET Core apps. The framework determines the route precedence for each segment first. The route's length is used only as a second criteria to break ties.
+
+## Reason for change
+
+The original behavior is considered a bug in the implementation. As a goal, the routing system in Blazor apps should behave the same way as the routing system in the rest of ASP.NET Core.
+
+## Recommended action
+
+If upgrading from previous versions of Blazor to 5.x, use the `PreferExactMatches` attribute on the `Router` component. This attribute can be used to opt in to the correct behavior. For example:
+
+```razor
+
+```
+
+When `PreferExactMatches` is set to `true`, route matching prefers exact matches over wildcards.
+
+## Affected APIs
+
+None
+
+
diff --git a/aspnetcore/breaking-changes/5/blazor-static-web-assets-validation-logic-updated.md b/aspnetcore/breaking-changes/5/blazor-static-web-assets-validation-logic-updated.md
new file mode 100644
index 000000000000..eee04f71b11e
--- /dev/null
+++ b/aspnetcore/breaking-changes/5/blazor-static-web-assets-validation-logic-updated.md
@@ -0,0 +1,55 @@
+---
+title: "Breaking change: Blazor: Updated validation logic for static web assets"
+description: "Learn about the breaking change in ASP.NET Core 5.0 titled Blazor: Updated validation logic for static web assets"
+ms.author: scaddie
+ms.date: 10/01/2020
+ms.custom: https://github.com/aspnet/Announcements/issues/443
+---
+# Blazor: Updated validation logic for static web assets
+
+There was an issue in conflict validation for static web assets in ASP.NET Core 3.1 and Blazor WebAssembly 3.2. The issue:
+
+* Prevented proper conflict detection between the host assets and assets from Razor Class Libraries (RCLs) and Blazor WebAssembly apps.
+* Mostly affects Blazor WebAssembly apps, since by default, static web assets in RCLs are served under the `_content/$(PackageId)` prefix.
+
+## Version introduced
+
+5.0
+
+## Old behavior
+
+During development, an RCL's static web assets could be silently overridden with host project assets on the same host path. Consider an RCL that has defined a static web asset to be served at */folder/file.txt*. If the host placed a file at *wwwroot/folder/file.txt*, the file on the server silently overrode the file on the RCL or Blazor WebAssembly app.
+
+## New behavior
+
+ASP.NET Core correctly detects when this issue happens. It informs you, the user, of the conflict so that you can take the appropriate action.
+
+## Reason for change
+
+Static web assets weren't intended to be overridable by files on the *wwwroot* host of the project. Allowing for the overriding of those files could lead to errors that are difficult to diagnose. The result could be undefined behavior changes in published apps.
+
+## Recommended action
+
+By default, there's no reason for an RCL file to conflict with a file on the host. RCL files are prefixed with `_content/${PackageId}`. Blazor WebAssembly files are placed at the root of the host URL space, which makes conflicts easier. For example, Blazor WebAssembly apps contain a *favicon.ico* file that the host might also include in its *wwwroot* folder.
+
+If the conflict's source is an RCL file, it often means code is copying assets from the library into the project's *wwwroot* folder. Writing code to copy files defeats a primary goal of static web assets. This goal is fundamental to get updates on the browser when the contents are updated without having to trigger a new compilation.
+
+You may choose to preserve this behavior and maintain the file on the host. To do so, remove the file from the list of static web assets with a custom MSBuild target.
+
+To use the RCL's file or the Blazor WebAssembly app's file instead of the host project's file, remove the file from the host project.
+
+## Affected APIs
+
+None
+
+
diff --git a/aspnetcore/breaking-changes/5/extensions-package-reference-changes.md b/aspnetcore/breaking-changes/5/extensions-package-reference-changes.md
new file mode 100644
index 000000000000..3d2e57ab6221
--- /dev/null
+++ b/aspnetcore/breaking-changes/5/extensions-package-reference-changes.md
@@ -0,0 +1,59 @@
+---
+title: "Breaking change: Extensions: Package reference changes affecting some NuGet packages"
+description: "Learn about the breaking change in ASP.NET Core 5.0 titled Extensions: Package reference changes affecting some NuGet packages"
+ms.author: scaddie
+ms.date: 10/01/2020
+ms.custom: https://github.com/aspnet/Announcements/issues/411
+---
+# Extensions: Package reference changes affecting some NuGet packages
+
+With the migration of some `Microsoft.Extensions.*` NuGet packages from the [dotnet/extensions](https://github.com/dotnet/extensions) repository to [dotnet/runtime](https://github.com/dotnet/runtime), as described in [aspnet/Announcements#411](https://github.com/aspnet/Announcements/issues/411), packaging changes are being applied to some of the migrated packages. For discussion on this issue, see [dotnet/aspnetcore#21033](https://github.com/dotnet/aspnetcore/issues/21033).
+
+## Version introduced
+
+5.0 Preview 4
+
+## Old behavior
+
+Some `Microsoft.Extensions.*` packages included package references for APIs on which your app relied.
+
+## New behavior
+
+Your app may have to add `Microsoft.Extensions.*` package dependencies.
+
+## Reason for change
+
+Packaging policies were updated to better align with the *dotnet/runtime* repository. Under the new policy, unused package references are removed from *.nupkg* files during packaging.
+
+## Recommended action
+
+Consumers of the affected packages should add a direct dependency on the removed package dependency in their project if APIs from removed package dependency are used. The following table lists the affected packages and the corresponding changes.
+
+|Package name|Change description|
+|------------|------------------|
+|[Microsoft.Extensions.Configuration.Binder](https://nuget.org/packages/Microsoft.Extensions.Configuration.Binder)|Removed reference to `Microsoft.Extensions.Configuration`|
+|[Microsoft.Extensions.Configuration.Json](https://nuget.org/packages/Microsoft.Extensions.Configuration.Json) |Removed reference to `System.Threading.Tasks.Extensions`|
+|[Microsoft.Extensions.Hosting.Abstractions](https://nuget.org/packages/Microsoft.Extensions.Hosting.Abstractions)|Removed reference to `Microsoft.Extensions.Logging.Abstractions`|
+|[Microsoft.Extensions.Logging](https://nuget.org/packages/Microsoft.Extensions.Logging) |Removed reference to `Microsoft.Extensions.Configuration.Binder`|
+|[Microsoft.Extensions.Logging.Console](https://nuget.org/packages/Microsoft.Extensions.Logging.Console) |Removed reference to `Microsoft.Extensions.Configuration.Abstractions`|
+|[Microsoft.Extensions.Logging.EventLog](https://nuget.org/packages/Microsoft.Extensions.Logging.EventLog) |Removed reference to `System.Diagnostics.EventLog` for the .NET Framework 4.6.1 target framework moniker|
+|[Microsoft.Extensions.Logging.EventSource](https://nuget.org/packages/Microsoft.Extensions.Logging.EventSource) |Removed reference to `System.Threading.Tasks.Extensions`|
+|[Microsoft.Extensions.Options](https://nuget.org/packages/Microsoft.Extensions.Options) |Removed reference to `System.ComponentModel.Annotations`|
+
+For example, the package reference to `Microsoft.Extensions.Configuration` was removed from `Microsoft.Extensions.Configuration.Binder`. No API from the dependency was used in the package. Users of `Microsoft.Extensions.Configuration.Binder` who depend on APIs from `Microsoft.Extensions.Configuration` should add a direct reference to it in their project.
+
+## Affected APIs
+
+None
+
+
diff --git a/aspnetcore/breaking-changes/5/http-badhttprequestexception-obsolete.md b/aspnetcore/breaking-changes/5/http-badhttprequestexception-obsolete.md
new file mode 100644
index 000000000000..06b0544ab399
--- /dev/null
+++ b/aspnetcore/breaking-changes/5/http-badhttprequestexception-obsolete.md
@@ -0,0 +1,55 @@
+---
+title: "Breaking change: HTTP: Kestrel and IIS BadHttpRequestException types marked obsolete and replaced"
+description: "Learn about the breaking change in ASP.NET Core 5.0 titled HTTP: Kestrel and IIS BadHttpRequestException types marked obsolete and replaced"
+ms.author: scaddie
+ms.date: 10/01/2020
+ms.custom: https://github.com/aspnet/Announcements/issues/414
+---
+# HTTP: Kestrel and IIS BadHttpRequestException types marked obsolete and replaced
+
+`Microsoft.AspNetCore.Server.Kestrel.BadHttpRequestException` and `Microsoft.AspNetCore.Server.IIS.BadHttpRequestException` have been marked obsolete and changed to derive from `Microsoft.AspNetCore.Http.BadHttpRequestException`. The Kestrel and IIS servers still throw their old exception types for backwards compatibility. The obsolete types will be removed in a future release.
+
+For discussion, see [dotnet/aspnetcore#20614](https://github.com/dotnet/aspnetcore/issues/20614).
+
+## Version introduced
+
+5.0 Preview 4
+
+## Old behavior
+
+`Microsoft.AspNetCore.Server.Kestrel.BadHttpRequestException` and `Microsoft.AspNetCore.Server.IIS.BadHttpRequestException` derived from .
+
+## New behavior
+
+`Microsoft.AspNetCore.Server.Kestrel.BadHttpRequestException` and `Microsoft.AspNetCore.Server.IIS.BadHttpRequestException` are obsolete. The types also derive from `Microsoft.AspNetCore.Http.BadHttpRequestException`, which derives from `System.IO.IOException`.
+
+## Reason for change
+
+The change was made to:
+
+* Consolidate duplicate types.
+* Unify behavior across server implementations.
+
+An app can now catch the base exception `Microsoft.AspNetCore.Http.BadHttpRequestException` when using either Kestrel or IIS.
+
+## Recommended action
+
+Replace usages of `Microsoft.AspNetCore.Server.Kestrel.BadHttpRequestException` and `Microsoft.AspNetCore.Server.IIS.BadHttpRequestException` with `Microsoft.AspNetCore.Http.BadHttpRequestException`.
+
+## Affected APIs
+
+- [Microsoft.AspNetCore.Server.IIS.BadHttpRequestException](/dotnet/api/microsoft.aspnetcore.server.iis.badhttprequestexception?view=aspnetcore-3.1&preserve-view=false)
+- [Microsoft.AspNetCore.Server.Kestrel.BadHttpRequestException](/dotnet/api/microsoft.aspnetcore.server.kestrel.badhttprequestexception?view=aspnetcore-1.1&preserve-view=false)
+
+
diff --git a/aspnetcore/breaking-changes/5/http-httpclient-instances-log-integer-status-codes.md b/aspnetcore/breaking-changes/5/http-httpclient-instances-log-integer-status-codes.md
new file mode 100644
index 000000000000..d92c8e644c64
--- /dev/null
+++ b/aspnetcore/breaking-changes/5/http-httpclient-instances-log-integer-status-codes.md
@@ -0,0 +1,86 @@
+---
+title: "Breaking change: HTTP: HttpClient instances created by IHttpClientFactory log integer status codes"
+description: "Learn about the breaking change in ASP.NET Core 5.0 titled HTTP: HttpClient instances created by IHttpClientFactory log integer status codes"
+ms.author: scaddie
+ms.date: 10/01/2020
+ms.custom: https://github.com/aspnet/Announcements/issues/396
+---
+# HTTP: HttpClient instances created by IHttpClientFactory log integer status codes
+
+ instances created by log HTTP status codes as integers instead of with status code names.
+
+## Version introduced
+
+5.0 Preview 1
+
+## Old behavior
+
+Logging uses the textual descriptions of HTTP status codes. Consider the following log messages:
+
+```output
+Received HTTP response after 56.0044ms - OK
+End processing HTTP request after 70.0862ms - OK
+```
+
+## New behavior
+
+Logging uses the integer values of HTTP status codes. Consider the following log messages:
+
+```output
+Received HTTP response after 56.0044ms - 200
+End processing HTTP request after 70.0862ms - 200
+```
+
+## Reason for change
+
+The original behavior of this logging is inconsistent with other parts of ASP.NET Core that have always used integer values. The inconsistency makes logs difficult to query via structured logging systems such as [Elasticsearch](https://www.elastic.co/elasticsearch/). For more context, see [dotnet/extensions#1549](https://github.com/dotnet/extensions/issues/1549).
+
+Using integer values is more flexible than text because it allows queries on ranges of values.
+
+Adding another log value to capture the integer status code was considered. Unfortunately, doing so would introduce another inconsistency with the rest of ASP.NET Core. HttpClient logging and HTTP server/hosting logging use the same `StatusCode` key name already.
+
+## Recommended action
+
+The best option is to update logging queries to use the integer values of status codes. This option may cause some difficulty writing queries across multiple ASP.NET Core versions. However, using integers for this purpose is much more flexible for querying logs.
+
+If you need to force compatibility with the old behavior and use textual status codes, replace the `IHttpClientFactory` logging with your own:
+
+1. Copy the .NET Core 3.1 versions of the following classes into your project:
+
+ * [LoggingHttpMessageHandlerBuilderFilter](https://github.com/dotnet/extensions/blob/release/3.1/src/HttpClientFactory/Http/src/Logging/LoggingHttpMessageHandlerBuilderFilter.cs)
+ * [LoggingHttpMessageHandler](https://github.com/dotnet/extensions/blob/release/3.1/src/HttpClientFactory/Http/src/Logging/LoggingHttpMessageHandler.cs)
+ * [LoggingScopeHttpMessageHandler](https://github.com/dotnet/extensions/blob/release/3.1/src/HttpClientFactory/Http/src/Logging/LoggingScopeHttpMessageHandler.cs)
+ * [HttpHeadersLogValue](https://github.com/dotnet/extensions/blob/release/3.1/src/HttpClientFactory/Http/src/Logging/HttpHeadersLogValue.cs)
+
+1. Rename the classes to avoid conflicts with public types in the [Microsoft.Extensions.Http](https://www.nuget.org/packages/Microsoft.Extensions.Http) NuGet package.
+
+1. Replace the built-in implementation of `LoggingHttpMessageHandlerBuilderFilter` with your own in the project's `Startup.ConfigureServices` method. For example:
+
+ ```csharp
+ public void ConfigureServices(IServiceCollection services)
+ {
+ // Other service registrations go first. Code omitted for brevity.
+
+ // Place the following after all AddHttpClient registrations.
+ services.RemoveAll();
+
+ services.AddSingleton();
+ }
+ ```
+
+## Affected APIs
+
+
+
+
diff --git a/aspnetcore/breaking-changes/5/httpsys-client-certificate-renegotiation-disabled-by-default.md b/aspnetcore/breaking-changes/5/httpsys-client-certificate-renegotiation-disabled-by-default.md
new file mode 100644
index 000000000000..7682d77f4351
--- /dev/null
+++ b/aspnetcore/breaking-changes/5/httpsys-client-certificate-renegotiation-disabled-by-default.md
@@ -0,0 +1,54 @@
+---
+title: "Breaking change: HttpSys: Client certificate renegotiation disabled by default"
+description: "Learn about the breaking change in ASP.NET Core 5.0 titled HttpSys: Client certificate renegotiation disabled by default"
+ms.author: scaddie
+ms.date: 10/01/2020
+ms.custom: https://github.com/aspnet/Announcements/issues/422
+---
+# HttpSys: Client certificate renegotiation disabled by default
+
+The option to renegotiate a connection and request a client certificate has been disabled by default. For discussion, see issue [dotnet/aspnetcore#23181](https://github.com/dotnet/aspnetcore/issues/23181).
+
+## Version introduced
+
+ASP.NET Core 5.0
+
+## Old behavior
+
+The connection can be renegotiated to request a client certificate.
+
+## New behavior
+
+Client certificates can only be requested during the initial connection handshake. For more information, see pull request [dotnet/aspnetcore#23162](https://github.com/dotnet/aspnetcore/pull/23162).
+
+## Reason for change
+
+Renegotiation caused a number of performance and deadlock issues. It's also not supported in HTTP/2. For additional context from when the option to control this behavior was introduced in ASP.NET Core 3.1, see issue [dotnet/aspnetcore#14806](https://github.com/dotnet/aspnetcore/issues/14806).
+
+## Recommended action
+
+Apps that require client certificates should use *netsh.exe* to set the `clientcertnegotiation` option to `enabled`. For more information, see [netsh http commands](/windows-server/networking/technologies/netsh/netsh-http).
+
+If you want client certificates enabled for only some parts of your app, see the guidance at [Optional client certificates](/aspnet/core/security/authentication/certauth?view=aspnetcore-3.1#optional-client-certificates&preserve-view=false).
+
+If you need the old renegotiate behavior, set `HttpSysOptions.ClientCertificateMethod` to the old value `ClientCertificateMethod.AllowRenegotiate`. This isn't recommended for the reasons outlined above and in the linked guidance.
+
+## Affected APIs
+
+-
+-
+-
+
+
diff --git a/aspnetcore/breaking-changes/5/iis-urlrewrite-middleware-query-strings-are-preserved.md b/aspnetcore/breaking-changes/5/iis-urlrewrite-middleware-query-strings-are-preserved.md
new file mode 100644
index 000000000000..dfa3d0eb4315
--- /dev/null
+++ b/aspnetcore/breaking-changes/5/iis-urlrewrite-middleware-query-strings-are-preserved.md
@@ -0,0 +1,57 @@
+---
+title: "Breaking change: IIS: UrlRewrite middleware query strings are preserved"
+description: "Learn about the breaking change in ASP.NET Core 5.0 titled IIS: UrlRewrite middleware query strings are preserved"
+ms.author: scaddie
+ms.date: 10/01/2020
+ms.custom: https://github.com/aspnet/Announcements/issues/420
+---
+# IIS: UrlRewrite middleware query strings are preserved
+
+An IIS UrlRewrite middleware defect prevented the query string from being preserved in rewrite rules. That defect has been fixed to maintain consistency with the IIS UrlRewrite Module's behavior.
+
+For discussion, see issue [dotnet/aspnetcore#22972](https://github.com/dotnet/aspnetcore/issues/22972).
+
+## Version introduced
+
+ASP.NET Core 5.0
+
+## Old behavior
+
+Consider the following rewrite rule:
+
+```xml
+
+
+
+
+```
+
+The preceding rule doesn't append the query string. A URI like `/about?id=1` redirects to `/contact` instead of `/contact?id=1`. The `appendQueryString` attribute defaults to `true` as well.
+
+## New behavior
+
+The query string is preserved. The URI from the example in [Old behavior](#old-behavior) would be `/contact?id=1`.
+
+## Reason for change
+
+The old behavior didn't match the IIS UrlRewrite Module's behavior. To support porting between the middleware and module, the goal is to maintain consistent behaviors.
+
+## Recommended action
+
+If the behavior of removing the query string is preferred, set the `action` element to `appendQueryString="false"`.
+
+## Affected APIs
+
+
+
+
diff --git a/aspnetcore/breaking-changes/5/kestrel-configuration-changes-at-run-time-detected-by-default.md b/aspnetcore/breaking-changes/5/kestrel-configuration-changes-at-run-time-detected-by-default.md
new file mode 100644
index 000000000000..ec0f0dc77691
--- /dev/null
+++ b/aspnetcore/breaking-changes/5/kestrel-configuration-changes-at-run-time-detected-by-default.md
@@ -0,0 +1,108 @@
+---
+title: "Breaking change: Kestrel: Configuration changes at runtime detected by default"
+description: "Learn about the breaking change in ASP.NET Core 5.0 titled Kestrel: Configuration changes at runtime detected by default"
+ms.author: scaddie
+ms.date: 10/01/2020
+ms.custom: https://github.com/aspnet/Announcements/issues/419
+---
+# Kestrel: Configuration changes at runtime detected by default
+
+Kestrel now reacts to changes made to the `Kestrel` section of the project's `IConfiguration` instance (for example, *appsettings.json*) at runtime. To learn more about how to configure Kestrel using *appsettings.json*, see the *appsettings.json* example in [Endpoint configuration](/aspnet/core/fundamentals/servers/kestrel#endpoint-configuration).
+
+Kestrel will bind, unbind, and rebind endpoints as necessary to react to these configuration changes.
+
+For discussion, see issue [dotnet/aspnetcore#22807](https://github.com/dotnet/aspnetcore/issues/22807).
+
+## Version introduced
+
+5.0 Preview 7
+
+## Old behavior
+
+Before ASP.NET Core 5.0 Preview 6, Kestrel didn't support changing configuration at runtime.
+
+In ASP.NET Core 5.0 Preview 6, you could opt in to the now-default behavior of reacting to configuration changes at runtime. Opting in required binding Kestrel's configuration manually:
+
+```csharp
+using Microsoft.AspNetCore.Hosting;
+using Microsoft.Extensions.Hosting;
+
+public class Program
+{
+ public static void Main(string[] args) =>
+ CreateHostBuilder(args).Build().Run();
+
+ public static IHostBuilder CreateHostBuilder(string[] args) =>
+ Host.CreateDefaultBuilder(args)
+ .ConfigureWebHostDefaults(webBuilder =>
+ {
+ webBuilder.UseKestrel((builderContext, kestrelOptions) =>
+ {
+ kestrelOptions.Configure(
+ builderContext.Configuration.GetSection("Kestrel"), reloadOnChange: true);
+ });
+
+ webBuilder.UseStartup();
+ });
+}
+```
+
+## New behavior
+
+Kestrel reacts to configuration changes at runtime by default. To support that change, calls `KestrelServerOptions.Configure(IConfiguration, bool)` with `reloadOnChange: true` by default.
+
+## Reason for change
+
+The change was made to support endpoint reconfiguration at runtime without completely restarting the server. Unlike with a full server restart, unchanged endpoints aren't unbound even temporarily.
+
+## Recommended action
+
+* For most scenarios in which Kestrel's default configuration section doesn't change at runtime, this change has no impact and no action is needed.
+* For scenarios in which Kestrel's default configuration section does change at runtime and Kestrel should react to it, this is now the default behavior.
+* For scenarios in which Kestrel's default configuration section changes at runtime and Kestrel shouldn't react to it, you can opt out as follows:
+
+ ```csharp
+ using Microsoft.AspNetCore.Hosting;
+ using Microsoft.Extensions.Hosting;
+
+ public class Program
+ {
+ public static void Main(string[] args) =>
+ CreateHostBuilder(args).Build().Run();
+
+ public static IHostBuilder CreateHostBuilder(string[] args) =>
+ Host.CreateDefaultBuilder(args)
+ .ConfigureWebHostDefaults(webBuilder =>
+ {
+ webBuilder.UseKestrel((builderContext, kestrelOptions) =>
+ {
+ kestrelOptions.Configure(
+ builderContext.Configuration.GetSection("Kestrel"), reloadOnChange: false);
+ });
+
+ webBuilder.UseStartup();
+ });
+ }
+ ```
+
+**Notes:**
+
+This change doesn't modify the behavior of the `KestrelServerOptions.Configure(IConfiguration)` overload, which still defaults to the `reloadOnChange: false` behavior.
+
+It's also important to make sure the configuration source supports reloading. For JSON sources, reloading is configured by calling `AddJsonFile(path, reloadOnChange: true)`. Reloading is already configured by default for *appsettings.json* and *appsettings.{Environment}.json*.
+
+## Affected APIs
+
+
+
+
diff --git a/aspnetcore/breaking-changes/5/kestrel-default-supported-tls-protocol-versions-changed.md b/aspnetcore/breaking-changes/5/kestrel-default-supported-tls-protocol-versions-changed.md
new file mode 100644
index 000000000000..1f88ea8b79b7
--- /dev/null
+++ b/aspnetcore/breaking-changes/5/kestrel-default-supported-tls-protocol-versions-changed.md
@@ -0,0 +1,87 @@
+---
+title: "Breaking change: Kestrel: Default supported TLS protocol versions changed"
+description: "Learn about the breaking change in ASP.NET Core 5.0 titled Kestrel: Default supported TLS protocol versions changed"
+ms.author: scaddie
+ms.date: 10/01/2020
+ms.custom: https://github.com/aspnet/Announcements/issues/418
+---
+# Kestrel: Default supported TLS protocol versions changed
+
+Kestrel now uses the system default TLS protocol versions rather than restricting connections to the TLS 1.1 and TLS 1.2 protocols like it did previously.
+
+This change allows:
+
+* TLS 1.3 to be used by default in environments that support it.
+* TLS 1.0 to be used in some environments (such as Windows Server 2016 by default), which is usually [not desirable](/security/engineering/solving-tls1-problem).
+
+For discussion, see issue [dotnet/aspnetcore#22563](https://github.com/dotnet/aspnetcore/issues/22563).
+
+## Version introduced
+
+5.0 Preview 6
+
+## Old behavior
+
+Kestrel required that connections use TLS 1.1 or TLS 1.2 by default.
+
+## New behavior
+
+Kestrel allows the operating system to choose the best protocol to use and to block insecure protocols. now defaults to `SslProtocols.None` instead of `SslProtocols.Tls12 | SslProtocols.Tls11`.
+
+## Reason for change
+
+The change was made to support TLS 1.3 and future TLS versions by default as they become available.
+
+## Recommended action
+
+Unless your app has a specific reason not to, you should use the new defaults. Verify your system is configured to allow only secure protocols.
+
+To disable older protocols, take one of the following actions:
+
+* Disable older protocols, such as TLS 1.0, system-wide with the [Windows instructions](/dotnet/framework/network-programming/tls#configure-schannel-protocols-in-the-windows-registry). It's currently enabled by default on all Windows versions.
+* Manually select which protocols you want to support in code as follows:
+
+ ```csharp
+ using System.Security.Authentication;
+ using Microsoft.AspNetCore.Hosting;
+ using Microsoft.Extensions.Hosting;
+
+ public class Program
+ {
+ public static void Main(string[] args) =>
+ CreateHostBuilder(args).Build().Run();
+
+ public static IHostBuilder CreateHostBuilder(string[] args) =>
+ Host.CreateDefaultBuilder(args)
+ .ConfigureWebHostDefaults(webBuilder =>
+ {
+ webBuilder.UseKestrel(kestrelOptions =>
+ {
+ kestrelOptions.ConfigureHttpsDefaults(httpsOptions =>
+ {
+ httpsOptions.SslProtocols = SslProtocols.Tls12 | SslProtocols.Tls13;
+ });
+ });
+
+ webBuilder.UseStartup();
+ });
+ }
+ ```
+
+Unfortunately, there's no API to exclude specific protocols.
+
+## Affected APIs
+
+
+
+
diff --git a/aspnetcore/breaking-changes/5/kestrel-disables-http2-over-tls.md b/aspnetcore/breaking-changes/5/kestrel-disables-http2-over-tls.md
new file mode 100644
index 000000000000..f67ed6810720
--- /dev/null
+++ b/aspnetcore/breaking-changes/5/kestrel-disables-http2-over-tls.md
@@ -0,0 +1,76 @@
+---
+title: "Breaking change: Kestrel: HTTP/2 disabled over TLS on incompatible Windows versions"
+description: "Learn about the breaking change in ASP.NET Core 5.0 titled Kestrel: HTTP/2 disabled over TLS on incompatible Windows versions"
+ms.author: scaddie
+ms.date: 10/01/2020
+ms.custom: https://github.com/aspnet/Announcements/issues/421
+---
+# Kestrel: HTTP/2 disabled over TLS on incompatible Windows versions
+
+To enable HTTP/2 over Transport Layer Security (TLS) on Windows, two requirements need to be met:
+
+- Application-Layer Protocol Negotiation (ALPN) support, which is available starting with Windows 8.1 and Windows Server 2012 R2.
+- A set of ciphers compatible with HTTP/2, which is available starting with Windows 10 and Windows Server 2016.
+
+As such, Kestrel's behavior when HTTP/2 over TLS is configured has changed to:
+
+- Downgrade to `Http1` and log a message at the `Information` level when [ListenOptions.HttpProtocols](/dotnet/api/microsoft.aspnetcore.server.kestrel.core.httpprotocols) is set to `Http1AndHttp2`. `Http1AndHttp2` is the default value for `ListenOptions.HttpProtocols`.
+- Throw a `NotSupportedException` when `ListenOptions.HttpProtocols` is set to `Http2`.
+
+For discussion, see issue [dotnet/aspnetcore#23068](https://github.com/dotnet/aspnetcore/issues/23068).
+
+## Version introduced
+
+ASP.NET Core 5.0
+
+## Old behavior
+
+The following table outlines the behavior when HTTP/2 over TLS is configured.
+
+| Protocols | Windows 7,
Windows Server 2008 R2,
or earlier | Windows 8,
Windows Server 2012 | Windows 8.1,
Windows Server 2012 R2 | Windows 10,
Windows Server 2016,
or newer |
+|---------------|-----------------------------------------------|--------------------------------|-------------------------------------|------------------------------------------|
+| `Http2` | Throw `NotSupportedException` | Error during TLS handshake | Error during TLS handshake * | No error |
+| `Http1AndHttp2` | Downgrade to `Http1` | Downgrade to `Http1` | Error during TLS handshake * | No error |
+
+* Configure compatible cipher suites to enable these scenarios.
+
+## New behavior
+
+The following table outlines the behavior when HTTP/2 over TLS is configured.
+
+| Protocols | Windows 7,
Windows Server 2008 R2,
or earlier | Windows 8,
Windows Server 2012 | Windows 8.1,
Windows Server 2012 R2 | Windows 10,
Windows Server 2016,
or newer |
+|---------------|-----------------------------------------------|--------------------------------|-------------------------------------|------------------------------------------|
+| `Http2` | Throw `NotSupportedException` | Throw `NotSupportedException` | Throw `NotSupportedException` ** | No error |
+| `Http1AndHttp2` | Downgrade to `Http1` | Downgrade to `Http1` | Downgrade to `Http1` ** | No error |
+
+** Configure compatible cipher suites and set the app context switch `Microsoft.AspNetCore.Server.Kestrel.EnableWindows81Http2` to `true` to enable these scenarios.
+
+## Reason for change
+
+This change ensures compatibility errors for HTTP/2 over TLS on older Windows versions are surfaced as early and as clearly as possible.
+
+## Recommended action
+
+Ensure HTTP/2 over TLS is disabled on incompatible Windows versions. Windows 8.1 and Windows Server 2012 R2 are incompatible since they lack the necessary ciphers by default. However, it's possible to update the Computer Configuration settings to use HTTP/2 compatible ciphers. For more information, see [TLS cipher suites in Windows 8.1](/windows/win32/secauthn/tls-cipher-suites-in-windows-8-1). Once configured, HTTP/2 over TLS on Kestrel must be enabled by setting the app context switch `Microsoft.AspNetCore.Server.Kestrel.EnableWindows81Http2`. For example:
+
+```csharp
+AppContext.SetSwitch("Microsoft.AspNetCore.Server.Kestrel.EnableWindows81Http2", true);
+```
+
+No underlying support has changed. For example, HTTP/2 over TLS has never worked on Windows 8 or Windows Server 2012. This change modifies how errors in these unsupported scenarios are presented.
+
+## Affected APIs
+
+None
+
+
diff --git a/aspnetcore/breaking-changes/5/kestrel-libuv-transport-obsolete.md b/aspnetcore/breaking-changes/5/kestrel-libuv-transport-obsolete.md
new file mode 100644
index 000000000000..593aaeda0e2b
--- /dev/null
+++ b/aspnetcore/breaking-changes/5/kestrel-libuv-transport-obsolete.md
@@ -0,0 +1,66 @@
+---
+title: "Breaking change: Kestrel: Libuv transport marked as obsolete"
+description: "Learn about the breaking change in ASP.NET Core 5.0 titled Kestrel: Libuv transport marked as obsolete"
+ms.author: scaddie
+ms.date: 10/01/2020
+ms.custom: https://github.com/aspnet/Announcements/issues/424
+---
+# Kestrel: Libuv transport marked as obsolete
+
+Earlier versions of ASP.NET Core used Libuv as an implementation detail of how asynchronous input and output was performed. In ASP.NET Core 2.0, an alternative, -based transport was developed. In ASP.NET Core 2.1, Kestrel switched to using the `Socket`-based transport by default. Libuv support was maintained for compatibility reasons.
+
+At this point, use of the `Socket`-based transport is far more common than the Libuv transport. Consequently, Libuv support is marked as obsolete in .NET 5 and will be removed entirely in .NET 6.0.
+
+As part of this change, Libuv support for new operating system platforms (like Windows Arm64) won't be added in the .NET 5 timeframe.
+
+For discussion on blocking issues that require the use of the Libuv transport, see the GitHub issue at [dotnet/aspnetcore#23409](https://github.com/dotnet/aspnetcore/issues/23409).
+
+## Version introduced
+
+5.0 Preview 8
+
+## Old behavior
+
+The Libuv APIs aren't marked as obsolete.
+
+## New behavior
+
+The Libuv APIs are marked as obsolete.
+
+## Reason for change
+
+The `Socket`-based transport is the default. There aren't any compelling reasons to continue using the Libuv transport.
+
+## Recommended action
+
+Discontinue use of the [Libuv package](https://www.nuget.org/packages/Libuv) and extension methods.
+
+## Affected APIs
+
+- [WebHostBuilderLibuvExtensions](/dotnet/api/microsoft.aspnetcore.hosting.webhostbuilderlibuvextensions?view=aspnetcore-3.0&preserve-view=false)
+- [WebHostBuilderLibuvExtensions.UseLibuv](/dotnet/api/microsoft.aspnetcore.hosting.webhostbuilderlibuvextensions.uselibuv?view=aspnetcore-3.0&preserve-view=false)
+- [Microsoft.AspNetCore.Server.Kestrel.Transport.Libuv.LibuvTransportOptions](/dotnet/api/microsoft.aspnetcore.server.kestrel.transport.libuv.libuvtransportoptions?view=aspnetcore-3.0&preserve-view=false)
+- [Microsoft.AspNetCore.Server.Kestrel.Transport.Libuv.LibuvTransportOptions.ThreadCount](/dotnet/api/microsoft.aspnetcore.server.kestrel.transport.libuv.libuvtransportoptions.threadcount?view=aspnetcore-3.0&preserve-view=false)
+- [Microsoft.AspNetCore.Server.Kestrel.Transport.Libuv.LibuvTransportOptions.NoDelay](/dotnet/api/microsoft.aspnetcore.server.kestrel.transport.libuv.libuvtransportoptions.nodelay?view=aspnetcore-3.0&preserve-view=false)
+- [Microsoft.AspNetCore.Server.Kestrel.Transport.Libuv.LibuvTransportOptions.MaxWriteBufferSize](/dotnet/api/microsoft.aspnetcore.server.kestrel.transport.libuv.libuvtransportoptions.maxwritebuffersize?view=aspnetcore-3.0&preserve-view=false)
+- [Microsoft.AspNetCore.Server.Kestrel.Transport.Libuv.LibuvTransportOptions.MaxReadBufferSize](/dotnet/api/microsoft.aspnetcore.server.kestrel.transport.libuv.libuvtransportoptions.maxreadbuffersize?view=aspnetcore-3.0&preserve-view=false)
+- `Microsoft.AspNetCore.Server.Kestrel.Transport.Libuv.LibuvTransportOptions.Backlog`
+
+
diff --git a/aspnetcore/breaking-changes/5/localization-members-removed.md b/aspnetcore/breaking-changes/5/localization-members-removed.md
new file mode 100644
index 000000000000..34ca33fb7d71
--- /dev/null
+++ b/aspnetcore/breaking-changes/5/localization-members-removed.md
@@ -0,0 +1,37 @@
+---
+title: "Breaking change: Localization: ResourceManagerWithCultureStringLocalizer class and WithCulture interface member removed"
+description: "Learn about the breaking change in ASP.NET Core 5.0 titled Localization: ResourceManagerWithCultureStringLocalizer class and WithCulture interface member removed"
+ms.author: scaddie
+ms.date: 10/01/2020
+ms.custom: https://github.com/aspnet/Announcements/issues/346
+---
+# Localization: ResourceManagerWithCultureStringLocalizer class and WithCulture interface member removed
+
+The `Microsoft.Extensions.Localization.ResourceManagerWithCultureStringLocalizer` class and `Microsoft.Extensions.Localization.ResourceManagerStringLocalizer.WithCulture` method were removed in .NET 5.
+
+For context, see [aspnet/Announcements#346](https://github.com/aspnet/Announcements/issues/346) and [dotnet/aspnetcore#3324](https://github.com/dotnet/aspnetcore/issues/3324). For discussion on this change, see [dotnet/aspnetcore#7756](https://github.com/dotnet/aspnetcore/issues/7756).
+
+## Version introduced
+
+5.0
+
+## Old behavior
+
+The `ResourceManagerWithCultureStringLocalizer` class and the `ResourceManagerStringLocalizer.WithCulture` method are [obsolete in .NET Core 3.0 and later](/dotnet/core/compatibility/3.0#localization-resourcemanagerwithculturestringlocalizer-and-withculture-marked-obsolete).
+
+## New behavior
+
+The `ResourceManagerWithCultureStringLocalizer` class and the `ResourceManagerStringLocalizer.WithCulture` method have been removed in .NET 5. For an inventory of the changes made, see the pull request at [dotnet/extensions#2562](https://github.com/dotnet/extensions/pull/2562/files).
+
+## Reason for change
+
+The `ResourceManagerWithCultureStringLocalizer` class and `ResourceManagerStringLocalizer.WithCulture` method were often sources of confusion for users of localization. The confusion was especially high when creating a custom implementation. This class and method give consumers the impression that an `IStringLocalizer` instance is expected to be "per-language, per-resource". In reality, the instance should only be "per-resource". At runtime, the property determines the language to be used.
+
+## Recommended action
+
+Stop using the `ResourceManagerWithCultureStringLocalizer` class and the `ResourceManagerStringLocalizer.WithCulture` method.
+
+## Affected APIs
+
+- `Microsoft.Extensions.Localization.ResourceManagerWithCultureStringLocalizer`
+- `Microsoft.Extensions.Localization.ResourceManagerStringLocalizer.WithCulture`
diff --git a/aspnetcore/breaking-changes/5/localization-pubternal-apis-removed.md b/aspnetcore/breaking-changes/5/localization-pubternal-apis-removed.md
new file mode 100644
index 000000000000..3f9fd2a2f244
--- /dev/null
+++ b/aspnetcore/breaking-changes/5/localization-pubternal-apis-removed.md
@@ -0,0 +1,66 @@
+---
+title: "Breaking change: Pubternal APIs removed"
+description: "Learn about the breaking change in ASP.NET Core 5.0 where some pubternal localization APIs were removed"
+ms.author: scaddie
+ms.date: 10/01/2020
+ms.custom: https://github.com/aspnet/Announcements/issues/377
+---
+# Localization: "Pubternal" APIs removed
+
+To better maintain the public API surface of ASP.NET Core, some :::no-loc text="\"pubternal\""::: localization APIs were removed. A :::no-loc text="\"pubternal\""::: API has a `public` access modifier and is defined in a namespace that implies an [internal](/dotnet/csharp/language-reference/keywords/internal) intent.
+
+For discussion, see [dotnet/aspnetcore#22291](https://github.com/dotnet/aspnetcore/issues/22291).
+
+## Version introduced
+
+5.0 Preview 6
+
+## Old behavior
+
+The following APIs were `public`:
+
+- `Microsoft.Extensions.Localization.Internal.AssemblyWrapper`
+- `Microsoft.Extensions.Localization.Internal.IResourceStringProvider`
+- `Microsoft.Extensions.Localization.ResourceManagerStringLocalizer` constructor overloads accepting either of the following parameter types:
+ - `AssemblyWrapper`
+ - `IResourceStringProvider`
+
+## New behavior
+
+The following list outlines the changes:
+
+- `Microsoft.Extensions.Localization.Internal.AssemblyWrapper` became `Microsoft.Extensions.Localization.AssemblyWrapper` and is now `internal`.
+- `Microsoft.Extensions.Localization.Internal.IResourceStringProvider` became `Microsoft.Extensions.Localization.Internal.IResourceStringProvider` and is now `internal`.
+- `Microsoft.Extensions.Localization.ResourceManagerStringLocalizer` constructor overloads accepting either of the following parameter types are now `internal`:
+ - `AssemblyWrapper`
+ - `IResourceStringProvider`
+
+## Reason for change
+
+Explained more thoroughly at [aspnet/Announcements#377](https://github.com/aspnet/Announcements/issues/377#issue-473651882), :::no-loc text="\"pubternal\""::: types were removed from the `public` API surface. These changes adapt more classes to that design decision. The classes in question were intended as extension points for the team's internal testing.
+
+## Recommended action
+
+Although it's unlikely, some apps may intentionally or accidentally depend upon the :::no-loc text="\"pubternal\""::: types. See the [New behavior](#new-behavior) sections to determine how to migrate away from the types.
+
+If you've identified a scenario which the public API allowed before this change but doesn't now, file an issue at [dotnet/aspnetcore](https://github.com/dotnet/aspnetcore/issues).
+
+## Affected APIs
+
+- `Microsoft.Extensions.Localization.Internal.AssemblyWrapper`
+- `Microsoft.Extensions.Localization.Internal.IResourceStringProvider`
+-
+
+
diff --git a/aspnetcore/breaking-changes/5/localization-requestlocalizationmiddleware-constructor-removed.md b/aspnetcore/breaking-changes/5/localization-requestlocalizationmiddleware-constructor-removed.md
new file mode 100644
index 000000000000..e82ebbc4de06
--- /dev/null
+++ b/aspnetcore/breaking-changes/5/localization-requestlocalizationmiddleware-constructor-removed.md
@@ -0,0 +1,46 @@
+---
+title: "Breaking change: Localization: Obsolete constructor removed in request localization middleware"
+description: "Learn about the breaking change in ASP.NET Core 5.0 titled Localization: Obsolete constructor removed in request localization middleware"
+ms.author: scaddie
+ms.date: 10/01/2020
+ms.custom: https://github.com/aspnet/Announcements/issues/429
+---
+# Localization: Obsolete constructor removed in request localization middleware
+
+The constructor that lacks an parameter was marked as obsolete [in this commit](https://github.com/dotnet/aspnetcore/commit/ba8c6ccf6fd3eeb7fc42a159d362b15eae4fb3a0). In ASP.NET Core 5.0, the obsolete constructor was removed. For discussion, see [dotnet/aspnetcore#23785](https://github.com/dotnet/aspnetcore/issues/23785).
+
+## Version introduced
+
+5.0 Preview 8
+
+## Old behavior
+
+The obsolete `RequestLocalizationMiddleware.ctor(RequestDelegate, IOptions)` constructor exists.
+
+## New behavior
+
+The obsolete `RequestLocalizationMiddleware.ctor(RequestDelegate, IOptions)` constructor doesn't exist.
+
+## Reason for change
+
+This change ensures that the request localization middleware always has access to a logger.
+
+## Recommended action
+
+When manually constructing an instance of `RequestLocalizationMiddleware`, pass an `ILoggerFactory` instance in the constructor. If a valid `ILoggerFactory` instance isn't available in that context, consider passing the middleware constructor a instance.
+
+## Affected APIs
+
+[RequestLocalizationMiddleware.ctor(RequestDelegate, IOptions\)](/dotnet/api/microsoft.aspnetcore.localization.requestlocalizationmiddleware.-ctor?view=aspnetcore-3.1#Microsoft_AspNetCore_Localization_RequestLocalizationMiddleware__ctor_Microsoft_AspNetCore_Http_RequestDelegate_Microsoft_Extensions_Options_IOptions_Microsoft_AspNetCore_Builder_RequestLocalizationOptions__&preserve-view=false)
+
+
diff --git a/aspnetcore/breaking-changes/5/middleware-database-error-page-obsolete.md b/aspnetcore/breaking-changes/5/middleware-database-error-page-obsolete.md
new file mode 100644
index 000000000000..98a526c6f3a1
--- /dev/null
+++ b/aspnetcore/breaking-changes/5/middleware-database-error-page-obsolete.md
@@ -0,0 +1,85 @@
+---
+title: "Breaking change: Middleware: Database error page marked as obsolete"
+description: "Learn about the breaking change in ASP.NET Core 5.0 titled Middleware: Database error page marked as obsolete"
+ms.author: scaddie
+ms.date: 10/01/2020
+ms.custom: https://github.com/aspnet/Announcements/issues/432
+---
+# Middleware: Database error page marked as obsolete
+
+The [DatabaseErrorPageMiddleware](/dotnet/api/microsoft.aspnetcore.diagnostics.entityframeworkcore.databaseerrorpagemiddleware?view=aspnetcore-3.0&preserve-view=false) and its associated extension methods were marked as obsolete in ASP.NET Core 5.0. The middleware and extension methods will be removed in ASP.NET Core 6.0. The functionality will instead be provided by `DatabaseDeveloperPageExceptionFilter` and its extension methods.
+
+For discussion, see the GitHub issue at [dotnet/aspnetcore#24987](https://github.com/dotnet/aspnetcore/issues/24987).
+
+## Version introduced
+
+5.0 RC 1
+
+## Old behavior
+
+`DatabaseErrorPageMiddleware` and its associated extension methods weren't obsolete.
+
+## New behavior
+
+`DatabaseErrorPageMiddleware` and its associated extension methods are obsolete.
+
+## Reason for change
+
+`DatabaseErrorPageMiddleware` was migrated to an extensible API for the [developer exception page](/aspnet/core/fundamentals/error-handling#developer-exception-page). For more information on the extensible API, see GitHub issue [dotnet/aspnetcore#8536](https://github.com/dotnet/aspnetcore/issues/8536).
+
+## Recommended action
+
+Complete the following steps:
+
+1. Stop using `DatabaseErrorPageMiddleware` in your project. For example, remove the `UseDatabaseErrorPage` method call from `Startup.Configure`:
+
+ ```csharp
+ public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
+ {
+ if (env.IsDevelopment())
+ {
+ app.UseDatabaseErrorPage();
+ }
+ }
+ ```
+
+1. Add the developer exception page to your project. For example, call the method in `Startup.Configure`:
+
+ ```csharp
+ public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
+ {
+ if (env.IsDevelopment())
+ {
+ app.UseDeveloperExceptionPage();
+ }
+ }
+ ```
+
+1. Add the [Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore](https://www.nuget.org/packages/Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore) NuGet package to the project file.
+
+1. Add the database developer page exception filter to the services collection. For example, call the `AddDatabaseDeveloperPageExceptionFilter` method in `Startup.ConfigureServices`:
+
+ ```csharp
+ public void ConfigureServices(IServiceCollection services)
+ {
+ services.AddDatabaseDeveloperPageExceptionFilter();
+ }
+ ```
+
+## Affected APIs
+
+- [Microsoft.AspNetCore.Builder.DatabaseErrorPageExtensions.UseDatabaseErrorPage](/dotnet/api/microsoft.aspnetcore.builder.databaseerrorpageextensions.usedatabaseerrorpage?view=aspnetcore-3.0&preserve-view=false)
+- [Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore.DatabaseErrorPageMiddleware](/dotnet/api/microsoft.aspnetcore.diagnostics.entityframeworkcore.databaseerrorpagemiddleware?view=aspnetcore-3.0&preserve-view=false)
+
+
diff --git a/aspnetcore/breaking-changes/5/middleware-exception-handler-throws-original-exception.md b/aspnetcore/breaking-changes/5/middleware-exception-handler-throws-original-exception.md
new file mode 100644
index 000000000000..4a30eed03ab2
--- /dev/null
+++ b/aspnetcore/breaking-changes/5/middleware-exception-handler-throws-original-exception.md
@@ -0,0 +1,56 @@
+---
+title: "Breaking change: Middleware: Exception Handler Middleware throws original exception if handler not found"
+description: "Learn about the breaking change in ASP.NET Core 5.0 titled Middleware: Exception Handler Middleware throws original exception if handler not found"
+ms.author: scaddie
+ms.date: 10/01/2020
+ms.custom: https://github.com/aspnet/Announcements/issues/434
+---
+# Middleware: Exception Handler Middleware throws original exception if handler not found
+
+Before ASP.NET Core 5.0, the [Exception Handler Middleware](xref:Microsoft.AspNetCore.Builder.ExceptionHandlerExtensions.UseExceptionHandler%2A) executes the configured exception handler when an exception has occurred. If the exception handler, configured via , can't be found, an HTTP 404 response is produced. The response is misleading in that it:
+
+* Seems to be a user error.
+* Obscures the fact that an exception occurred on the server.
+
+To address the misleading error in ASP.NET Core 5.0, the `ExceptionHandlerMiddleware` throws the original exception if the exception handler can't be found. As a result, an HTTP 500 response is produced by the server. The response will be easier to examine in the server logs when debugging the error that occurred.
+
+For discussion, see GitHub issue [dotnet/aspnetcore#25288](https://github.com/dotnet/aspnetcore/issues/25288).
+
+## Version introduced
+
+5.0 RC 1
+
+## Old behavior
+
+The Exception Handler Middleware produces an HTTP 404 response if the configured exception handler can't be found.
+
+## New behavior
+
+The Exception Handler Middleware throws the original exception if the configured exception handler can't be found.
+
+## Reason for change
+
+The HTTP 404 error doesn't make it obvious that an exception occurred on the server. This change produces an HTTP 500 error to make it obvious that:
+
+* The problem isn't caused by a user error.
+* An exception was encountered on the server.
+
+## Recommended action
+
+There are no API changes. All existing apps will continue to compile and run. The exception thrown is handled by the server. For example, the exception is converted to an HTTP 500 error response by [Kestrel](/aspnet/core/fundamentals/servers/kestrel) or [HTTP.sys](/aspnet/core/fundamentals/servers/httpsys).
+
+## Affected APIs
+
+None
+
+
diff --git a/aspnetcore/breaking-changes/5/mvc-objectmodelvalidator-calls-new-overload.md b/aspnetcore/breaking-changes/5/mvc-objectmodelvalidator-calls-new-overload.md
new file mode 100644
index 000000000000..763f44c9607c
--- /dev/null
+++ b/aspnetcore/breaking-changes/5/mvc-objectmodelvalidator-calls-new-overload.md
@@ -0,0 +1,72 @@
+---
+title: "Breaking change: MVC: ObjectModelValidator calls a new overload of ValidationVisitor.Validate"
+description: "Learn about the breaking change in ASP.NET Core 5.0 titled MVC: ObjectModelValidator calls a new overload of ValidationVisitor.Validate"
+ms.author: scaddie
+ms.date: 10/01/2020
+ms.custom: https://github.com/aspnet/Announcements/issues/440
+---
+# MVC: ObjectModelValidator calls a new overload of ValidationVisitor.Validate
+
+In ASP.NET Core 5.0, an overload of the was added. The new overload accepts the top-level model instance that contains properties:
+
+```diff
+ bool Validate(ModelMetadata metadata, string key, object model, bool alwaysValidateAtTopLevel);
++ bool Validate(ModelMetadata metadata, string key, object model, bool alwaysValidateAtTopLevel, object container);
+```
+
+ invokes this new overload of `ValidationVisitor` to perform validation. This new overload is pertinent if your validation library integrates with ASP.NET Core MVC's model validation system.
+
+For discussion, see GitHub issue [dotnet/aspnetcore#26020](https://github.com/dotnet/aspnetcore/issues/26020).
+
+## Version introduced
+
+5.0
+
+## Old behavior
+
+`ObjectModelValidator` invokes the following overload during model validation:
+
+```csharp
+ValidationVisitor.Validate(ModelMetadata metadata, string key, object model, bool alwaysValidateAtTopLevel)
+```
+
+## New behavior
+
+`ObjectModelValidator` invokes the following overload during model validation:
+
+```csharp
+ValidationVisitor.Validate(ModelMetadata metadata, string key, object model, bool alwaysValidateAtTopLevel, object container)
+```
+
+## Reason for change
+
+This change was introduced to support validators, such as , that rely on inspection of other properties.
+
+## Recommended action
+
+Validation frameworks that rely on `ObjectModelValidator` to invoke the existing overload of `ValidationVisitor` must override the new method when targeting .NET 5 or later:
+
+```csharp
+public class MyCustomValidationVisitor : ValidationVisitor
+{
++ public override bool Validate(ModelMetadata metadata, string key, object model, bool alwaysValidateAtTopLevel, object container)
++ {
++ ...
+}
+```
+
+## Affected APIs
+
+
+
+
diff --git a/aspnetcore/breaking-changes/5/overview.md b/aspnetcore/breaking-changes/5/overview.md
new file mode 100644
index 000000000000..0c416131d042
--- /dev/null
+++ b/aspnetcore/breaking-changes/5/overview.md
@@ -0,0 +1,49 @@
+---
+title: Breaking changes in ASP.NET Core 5
+description: Navigate to the breaking changes in ASP.NET Core 5.
+ms.date: 12/14/2020
+---
+# Breaking changes in ASP.NET Core 5
+
+If you're migrating an app to ASP.NET Core 5, the breaking changes listed here might affect you. Changes are grouped by technology area, such as ASP.NET Core or cryptography.
+
+[!INCLUDE [binary-source-compat](../includes/binary-source-compat.md)]
+
+| Title | Binary compatible | Source compatible |
+| - | - | - |
+| [ASP.NET Core apps deserialize quoted numbers](/dotnet/core/compatibility/serialization/5.0/jsonserializer-allows-reading-numbers-as-strings) | ✔️ | ❌ |
+| [AzureAD.UI and AzureADB2C.UI APIs obsolete](authentication-aad-packages-obsolete.md) | ✔️ | ❌ |
+| [BinaryFormatter serialization methods are obsolete](/dotnet/core/compatibility/serialization/5.0/binaryformatter-serialization-obsolete) | ✔️ | ❌ |
+| [Resource in endpoint routing is HttpContext](authorization-resource-in-endpoint-routing.md) | ✔️ | ❌ |
+| [Microsoft-prefixed Azure integration packages removed](azure-integration-packages-removed.md) | ❌ | ✔️ |
+| [Blazor: Route precedence logic changed in Blazor apps](blazor-routing-logic-changed.md) | ✔️ | ❌ |
+| [Blazor: Updated browser support](blazor-browser-support-updated.md) | ✔️ | ✔️ |
+| [Blazor: Insignificant whitespace trimmed by compiler](blazor-components-trim-insignificant-whitespace.md) | ✔️ | ❌ |
+| [Blazor: JSObjectReference and JSInProcessObjectReference types are internal](blazor-jsobjectreference-to-internal.md) | ✔️ | ❌ |
+| [Blazor: Target framework of NuGet packages changed](blazor-packages-target-framework-changed.md) | ❌ | ✔️ |
+| [Blazor: ProtectedBrowserStorage feature moved to shared framework](blazor-protectedbrowserstorage-moved.md) | ✔️ | ❌ |
+| [Blazor: RenderTreeFrame readonly public fields are now properties](blazor-rendertreeframe-fields-become-properties.md) | ❌ | ✔️ |
+| [Blazor: Updated validation logic for static web assets](blazor-static-web-assets-validation-logic-updated.md) | ❌ | ✔️ |
+| [Cryptography APIs not supported on browser](/dotnet/core/compatibility/cryptography/5.0/cryptography-apis-not-supported-on-blazor-webassembly) | ❌ | ✔️ |
+| [Extensions: Package reference changes](extensions-package-reference-changes.md) | ❌ | ✔️ |
+| [Kestrel and IIS BadHttpRequestException types are obsolete](http-badhttprequestexception-obsolete.md) | ✔️ | ❌ |
+| [HttpClient instances created by IHttpClientFactory log integer status codes](http-httpclient-instances-log-integer-status-codes.md) | ✔️ | ❌ |
+| [HttpSys: Client certificate renegotiation disabled by default](httpsys-client-certificate-renegotiation-disabled-by-default.md) | ✔️ | ❌ |
+| [IIS: UrlRewrite middleware query strings are preserved](iis-urlrewrite-middleware-query-strings-are-preserved.md) | ✔️ | ❌ |
+| [Kestrel: Configuration changes detected by default](kestrel-configuration-changes-at-run-time-detected-by-default.md) | ✔️ | ❌ |
+| [Kestrel: Default supported TLS protocol versions changed](kestrel-default-supported-tls-protocol-versions-changed.md) | ✔️ | ❌ |
+| [Kestrel: HTTP/2 disabled over TLS on incompatible Windows versions](kestrel-disables-http2-over-tls.md) | ✔️ | ✔️ |
+| [Kestrel: Libuv transport marked as obsolete](kestrel-libuv-transport-obsolete.md) | ✔️ | ❌ |
+| [Obsolete properties on ConsoleLoggerOptions](/dotnet/core/compatibility/core-libraries/5.0/obsolete-consoleloggeroptions-properties) | ✔️ | ❌ |
+| [ResourceManagerWithCultureStringLocalizer class and WithCulture interface member removed](localization-members-removed.md) | ✔️ | ❌ |
+| [Pubternal APIs removed](localization-pubternal-apis-removed.md) | ✔️ | ❌ |
+| [Obsolete constructor removed in request localization middleware](localization-requestlocalizationmiddleware-constructor-removed.md) | ✔️ | ❌ |
+| [Middleware: Database error page marked as obsolete](middleware-database-error-page-obsolete.md) | ✔️ | ❌ |
+| [Exception handler middleware throws original exception](middleware-exception-handler-throws-original-exception.md) | ✔️ | ✔️ |
+| [ObjectModelValidator calls a new overload of Validate](mvc-objectmodelvalidator-calls-new-overload.md) | ✔️ | ❌ |
+| [Cookie name encoding removed](security-cookie-name-encoding-removed.md) | ✔️ | ❌ |
+| [IdentityModel NuGet package versions updated](security-identitymodel-nuget-package-versions-updated.md) | ❌ | ✔️ |
+| [SignalR: MessagePack Hub Protocol options type changed](signalr-messagepack-hub-protocol-options-changed.md) | ✔️ | ❌ |
+| [SignalR: MessagePack Hub Protocol moved](signalr-messagepack-package.md) | ✔️ | ❌ |
+| [UseSignalR and UseConnections methods removed](signalr-usesignalr-useconnections-removed.md) | ✔️ | ❌ |
+| [CSV content type changed to standards-compliant](static-files-csv-content-type-changed.md) | ✔️ | ❌ |
diff --git a/aspnetcore/breaking-changes/5/security-cookie-name-encoding-removed.md b/aspnetcore/breaking-changes/5/security-cookie-name-encoding-removed.md
new file mode 100644
index 000000000000..9f256bc2929a
--- /dev/null
+++ b/aspnetcore/breaking-changes/5/security-cookie-name-encoding-removed.md
@@ -0,0 +1,59 @@
+---
+title: "Breaking change: Security: Cookie name encoding removed"
+description: "Learn about the breaking change in ASP.NET Core 5.0 titled Security: Cookie name encoding removed"
+ms.author: scaddie
+ms.date: 10/01/2020
+ms.custom: https://github.com/aspnet/Announcements/issues/427
+---
+# Security: Cookie name encoding removed
+
+The [HTTP cookie standard](https://tools.ietf.org/html/rfc6265#section-4.1.1) allows only specific characters in cookie names and values. To support disallowed characters, ASP.NET Core:
+
+* Encodes when creating a response cookie.
+* Decodes when reading a request cookie.
+
+In ASP.NET Core 5.0, this encoding behavior changed in response to a security concern.
+
+For discussion, see GitHub issue [dotnet/aspnetcore#23578](https://github.com/dotnet/aspnetcore/issues/23578).
+
+## Version introduced
+
+5.0 Preview 8
+
+## Old behavior
+
+Response cookie names are encoded. Request cookie names are decoded.
+
+## New behavior
+
+Encoding and decoding of cookie names was removed. For prior [supported versions](https://dotnet.microsoft.com/platform/support/policy/dotnet-core) of ASP.NET Core, the team plans to mitigate the decoding issue in-place. Additionally, calling with an invalid cookie name throws an exception of type . Encoding and decoding of cookie values remains unchanged.
+
+## Reason for change
+
+An issue was discovered in [multiple web frameworks](https://github.com/advisories/GHSA-j6w9-fv6q-3q52). The encoding and decoding could allow an attacker to bypass a security feature called [cookie prefixes](https://tools.ietf.org/html/draft-ietf-httpbis-cookie-prefixes-00) by spoofing reserved prefixes like `__Host-` with encoded values like `__%48ost-`. The attack requires a secondary exploit to inject the spoofed cookies, such as a cross-site scripting (XSS) vulnerability, in the website. These prefixes aren't used by default in ASP.NET Core or `Microsoft.Owin` libraries or templates.
+
+## Recommended action
+
+If you're moving projects to ASP.NET Core 5.0 or later, ensure that their cookie names conform to the [token specification requirements](https://tools.ietf.org/html/rfc2616#section-2.2): ASCII characters excluding controls and separators `"(" | ")" | "<" | ">" | "@" | "," | ";" | ":" | "\" | <"> | "/" | "[" | "]" | "?" | "=" | "{" | "}" | SP | HT`. The use of non-ASCII characters in cookie names or other HTTP headers may cause an exception from the server or be improperly round-tripped by the client.
+
+## Affected APIs
+
+-
+-
+- `Microsoft.Owin.IOwinRequest.Cookies`
+- `Microsoft.Owin.IOwinResponse.Cookies`
+
+
diff --git a/aspnetcore/breaking-changes/5/security-identitymodel-nuget-package-versions-updated.md b/aspnetcore/breaking-changes/5/security-identitymodel-nuget-package-versions-updated.md
new file mode 100644
index 000000000000..26d62815111a
--- /dev/null
+++ b/aspnetcore/breaking-changes/5/security-identitymodel-nuget-package-versions-updated.md
@@ -0,0 +1,51 @@
+---
+title: "Breaking change: Security: IdentityModel NuGet package versions updated"
+description: "Learn about the breaking change in ASP.NET Core 5.0 titled Security: IdentityModel NuGet package versions updated"
+ms.author: scaddie
+ms.date: 10/01/2020
+ms.custom: https://github.com/aspnet/Announcements/issues/428
+---
+# Security: IdentityModel NuGet package versions updated
+
+The following packages were updated to version 6.6.0:
+
+- [Microsoft.IdentityModel.Logging](https://www.nuget.org/packages/Microsoft.IdentityModel.Logging)
+- [Microsoft.IdentityModel.Protocols.OpenIdConnect](https://www.nuget.org/packages/Microsoft.IdentityModel.Protocols.OpenIdConnect)
+- [Microsoft.IdentityModel.Protocols.WsFederation](https://www.nuget.org/packages/Microsoft.IdentityModel.Protocols.WsFederation)
+- [System.IdentityModel.Tokens.Jwt](https://www.nuget.org/packages/System.IdentityModel.Tokens.Jwt)
+
+## Version introduced
+
+5.0 Preview 7
+
+## Old behavior
+
+The package version used is 5.5.0.
+
+## New behavior
+
+For details about changes between package versions, see the [6.6.0 release notes](https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/releases/tag/6.6.0).
+
+## Reason for change
+
+The packages were updated to take advantage of improvements in the underlying libraries.
+
+## Recommended action
+
+The package updates don't introduce public API changes to ASP.NET Core. However, it's possible there are breaking changes in the packages themselves.
+
+## Affected APIs
+
+None
+
+
diff --git a/aspnetcore/breaking-changes/5/signalr-messagepack-hub-protocol-options-changed.md b/aspnetcore/breaking-changes/5/signalr-messagepack-hub-protocol-options-changed.md
new file mode 100644
index 000000000000..8aa76f79e577
--- /dev/null
+++ b/aspnetcore/breaking-changes/5/signalr-messagepack-hub-protocol-options-changed.md
@@ -0,0 +1,91 @@
+---
+title: "Breaking change: SignalR: MessagePack Hub Protocol options type changed"
+description: "Learn about the breaking change in ASP.NET Core 5.0 titled SignalR: MessagePack Hub Protocol options type changed"
+ms.author: scaddie
+ms.date: 10/01/2020
+ms.custom: https://github.com/aspnet/Announcements/issues/404
+---
+# SignalR: MessagePack Hub Protocol options type changed
+
+The ASP.NET Core SignalR MessagePack Hub Protocol options type has changed from `IList` to the [MessagePack](https://www.nuget.org/packages/MessagePack) library's `MessagePackSerializerOptions` type.
+
+For discussion on this change, see [dotnet/aspnetcore#20506](https://github.com/dotnet/aspnetcore/issues/20506).
+
+## Version introduced
+
+5.0 Preview 4
+
+## Old behavior
+
+You can add to the options as shown in the following example:
+
+```csharp
+services.AddSignalR()
+ .AddMessagePackProtocol(options =>
+ {
+ options.FormatterResolvers.Add(MessagePack.Resolvers.StandardResolver.Instance);
+ });
+```
+
+And replace the options as follows:
+
+```csharp
+services.AddSignalR()
+ .AddMessagePackProtocol(options =>
+ {
+ options.FormatterResolvers = new List()
+ {
+ MessagePack.Resolvers.StandardResolver.Instance
+ };
+ });
+```
+
+## New behavior
+
+You can add to the options as shown in the following example:
+
+```csharp
+services.AddSignalR()
+ .AddMessagePackProtocol(options =>
+ {
+ options.SerializerOptions =
+ options.SerializeOptions.WithResolver(MessagePack.Resolvers.StandardResolver.Instance);
+ });
+```
+
+And replace the options as follows:
+
+```csharp
+services.AddSignalR()
+ .AddMessagePackProtocol(options =>
+ {
+ options.SerializerOptions = MessagePackSerializerOptions
+ .Standard
+ .WithResolver(MessagePack.Resolvers.StandardResolver.Instance)
+ .WithSecurity(MessagePackSecurity.UntrustedData);
+ });
+```
+
+## Reason for change
+
+This change is part of moving to MessagePack v2.x, which was announced in [aspnet/Announcements#404](https://github.com/aspnet/Announcements/issues/404). The v2.x library has added an options API that's easier to use and provides more features than the list of `MessagePack.IFormatterResolver` that was exposed before.
+
+## Recommended action
+
+This breaking change affects anyone who is configuring values on . If you're using the ASP.NET Core SignalR MessagePack Hub Protocol and modifying the options, update your usage to use the new options API as shown above.
+
+## Affected APIs
+
+
+
+
diff --git a/aspnetcore/breaking-changes/5/signalr-messagepack-package.md b/aspnetcore/breaking-changes/5/signalr-messagepack-package.md
new file mode 100644
index 000000000000..376297179e7b
--- /dev/null
+++ b/aspnetcore/breaking-changes/5/signalr-messagepack-package.md
@@ -0,0 +1,53 @@
+---
+title: "Breaking change: SignalR: MessagePack Hub Protocol moved to MessagePack 2.x package"
+description: "Learn about the breaking change in ASP.NET Core 5.0 titled SignalR: MessagePack Hub Protocol moved to MessagePack 2.x package"
+ms.author: scaddie
+ms.date: 10/01/2020
+ms.custom: https://github.com/aspnet/Announcements/issues/404
+---
+# SignalR: MessagePack Hub Protocol moved to MessagePack 2.x package
+
+The ASP.NET Core SignalR [MessagePack Hub Protocol](/aspnet/core/signalr/messagepackhubprotocol) uses the [MessagePack NuGet package](https://www.nuget.org/packages/MessagePack) for MessagePack serialization. ASP.NET Core 5.0 upgrades the package from 1.x to the latest 2.x package version.
+
+For discussion on this issue, see [dotnet/aspnetcore#18692](https://github.com/dotnet/aspnetcore/issues/18692).
+
+## Version introduced
+
+5.0 Preview 1
+
+## Old behavior
+
+ASP.NET Core SignalR used the MessagePack 1.x package to serialize and deserialize MessagePack messages.
+
+## New behavior
+
+ASP.NET Core SignalR uses the MessagePack 2.x package to serialize and deserialize MessagePack messages.
+
+## Reason for change
+
+The latest improvements in the MessagePack 2.x package add useful functionality.
+
+## Recommended action
+
+This breaking change applies when:
+
+* Setting or configuring values on .
+* Using the MessagePack APIs directly and using the ASP.NET Core SignalR MessagePack Hub Protocol in the same project. The newer version will be loaded instead of the previous version.
+
+For migration guidance from the package authors, see [Migrating from MessagePack v1.x to MessagePack v2.x](https://github.com/neuecc/MessagePack-CSharp/blob/master/doc/migration.md). Some aspects of message serialization and deserialization are affected. Specifically, there are [behavioral changes to how DateTime values are serialized](https://github.com/neuecc/MessagePack-CSharp/blob/master/doc/migration.md#behavioral-changes).
+
+## Affected APIs
+
+
+
+
diff --git a/aspnetcore/breaking-changes/5/signalr-usesignalr-useconnections-removed.md b/aspnetcore/breaking-changes/5/signalr-usesignalr-useconnections-removed.md
new file mode 100644
index 000000000000..e3283f15dd9c
--- /dev/null
+++ b/aspnetcore/breaking-changes/5/signalr-usesignalr-useconnections-removed.md
@@ -0,0 +1,76 @@
+---
+title: "Breaking change: SignalR: UseSignalR and UseConnections methods removed"
+description: "Learn about the breaking change in ASP.NET Core 5.0 titled SignalR: UseSignalR and UseConnections methods removed"
+ms.author: scaddie
+ms.date: 10/01/2020
+ms.custom: https://github.com/aspnet/Announcements/issues/412
+---
+# SignalR: UseSignalR and UseConnections methods removed
+
+In ASP.NET Core 3.0, SignalR adopted endpoint routing. As part of that change, the , , and some related methods were marked as obsolete. In ASP.NET Core 5.0, those obsolete methods were removed. For the full list of methods, see [Affected APIs](#affected-apis).
+
+For discussion on this issue, see [dotnet/aspnetcore#20082](https://github.com/dotnet/aspnetcore/issues/20082).
+
+## Version introduced
+
+5.0 Preview 3
+
+## Old behavior
+
+SignalR hubs and connection handlers could be registered in the middleware pipeline using the `UseSignalR` or `UseConnections` methods.
+
+## New behavior
+
+SignalR hubs and connection handlers should be registered within using the and extension methods on .
+
+## Reason for change
+
+The old methods had custom routing logic that didn't interact with other routing components in ASP.NET Core. In ASP.NET Core 3.0, a new general-purpose routing system, called endpoint routing, was introduced. Endpoint routing enabled SignalR to interact with other routing components. Switching to this model allows users to realize the full benefits of endpoint routing. Consequently, the old methods have been removed.
+
+## Recommended action
+
+Remove code that calls `UseSignalR` or `UseConnections` from your project's `Startup.Configure` method. Replace it with calls to `MapHub` or `MapConnectionHandler`, respectively, within the body of a call to `UseEndpoints`. For example:
+
+**Old code:**
+
+```csharp
+app.UseSignalR(routes =>
+{
+ routes.MapHub("/path");
+});
+```
+
+**New code:**
+
+```csharp
+app.UseEndpoints(endpoints =>
+{
+ endpoints.MapHub("/path");
+});
+```
+
+In general, your previous `MapHub` and `MapConnectionHandler` calls can be transferred directly from the body of `UseSignalR` and `UseConnections` to `UseEndpoints` with little-to-no change needed.
+
+## Affected APIs
+
+-
+-
+-
+-
+-
+
+
diff --git a/aspnetcore/breaking-changes/5/static-files-csv-content-type-changed.md b/aspnetcore/breaking-changes/5/static-files-csv-content-type-changed.md
new file mode 100644
index 000000000000..47ac942b3155
--- /dev/null
+++ b/aspnetcore/breaking-changes/5/static-files-csv-content-type-changed.md
@@ -0,0 +1,60 @@
+---
+title: "Breaking change: Static files: CSV content type changed to standards-compliant"
+description: "Learn about the breaking change in ASP.NET Core 5.0 titled Static files: CSV content type changed to standards-compliant"
+ms.author: scaddie
+ms.date: 10/01/2020
+ms.custom: https://github.com/aspnet/Announcements/issues/395
+---
+# Static files: CSV content type changed to standards-compliant
+
+In ASP.NET Core 5.0, the default `Content-Type` response header value that the [Static File Middleware](/aspnet/core/fundamentals/static-files) uses for *.csv* files has changed to the standards-compliant value `text/csv`.
+
+For discussion on this issue, see [dotnet/aspnetcore#17385](https://github.com/dotnet/AspNetCore/issues/17385).
+
+## Version introduced
+
+5.0 Preview 1
+
+## Old behavior
+
+The `Content-Type` header value `application/octet-stream` was used.
+
+## New behavior
+
+The `Content-Type` header value `text/csv` is used.
+
+## Reason for change
+
+Compliance with the [RFC 7111](https://tools.ietf.org/html/rfc7111#section-5.1) standard.
+
+## Recommended action
+
+If this change impacts your app, you can customize the file extension-to-MIME type mapping. To revert to the `application/octet-stream` MIME type, modify the method call in `Startup.Configure`. For example:
+
+```csharp
+var provider = new FileExtensionContentTypeProvider();
+provider.Mappings[".csv"] = MediaTypeNames.Application.Octet;
+
+app.UseStaticFiles(new StaticFileOptions
+{
+ ContentTypeProvider = provider
+});
+```
+
+For more information on customizing the mapping, see [FileExtensionContentTypeProvider](/aspnet/core/fundamentals/static-files#fileextensioncontenttypeprovider).
+
+## Affected APIs
+
+
+
+
diff --git a/aspnetcore/breaking-changes/6/actionresult-statuscode.md b/aspnetcore/breaking-changes/6/actionresult-statuscode.md
new file mode 100644
index 000000000000..26e02def994d
--- /dev/null
+++ b/aspnetcore/breaking-changes/6/actionresult-statuscode.md
@@ -0,0 +1,93 @@
+---
+title: "Breaking change: ActionResult sets StatusCode to 200"
+description: "Learn about the breaking change in ASP.NET Core 6.0 where ActionResult always sets the status code to 200, even if it was set manually."
+ms.date: 05/23/2022
+ms.custom: https://github.com/aspnet/Announcements/issues/485
+---
+# ActionResult\ sets StatusCode to 200
+
+When returning a `T` in an MVC/API controller action that declares the return type as , the is always set to 200, except when the `T` is a .
+
+This change can cause unexpected behavior in some scenarios where you set the status code manually, since previously the was `null`. Also, an action filter could be affected by this change if it expects a null value instead of 200.
+
+## Version introduced
+
+ASP.NET Core 6.0
+
+## Previous behavior
+
+Previously, a controller's action that returns `T` and sets `Response.StatusCode` manually generated the specified response status code. For example, the following controller's action will generate a `202 Accepted` response.
+
+```csharp
+// Generates a 202 Accepted response
+public ActionResult Get()
+{
+ Response.StatusCode = StatusCodes.Status202Accepted;
+ return new Model();
+}
+```
+
+## New behavior
+
+Now, the same controller's action that returns `T` and sets `Response.StatusCode` manually always generates a `200 OK` response.
+
+```csharp
+// Generates a 200 OK response
+public ActionResult Get()
+{
+ Response.StatusCode = StatusCodes.Status202Accepted;
+ return new Model();
+}
+```
+
+## Type of breaking change
+
+This change can affect [source compatibility](/dotnet/core/compatibility/categories#source-compatibility).
+
+## Reason for change
+
+Returning a status code of `200 OK` is [documented since ASP.NET Core 3.1](/aspnet/core/web-api/action-return-types#actionresultt-type). However, it keeps as `null` and eventually generates a `200 OK` response only because it's the default. Since the default internal behavior could change, we decided to avoid relying on the default and to explicitly set to the expected `200 OK`.
+
+## Recommended action
+
+If your code sets the status code manually and is broken by this change, you'll need to change your controller action. For example, the following code snippet sets a status code of 202 and is broken by this change.
+
+```csharp
+public ActionResult Get()
+{
+ Response.StatusCode = StatusCodes.Status202Accepted;
+ return new Model();
+}
+```
+
+To retain the desired behavior of a 202 status code, the following code snippets show some options.
+
+```csharp
+public ActionResult Get()
+{
+ return Accepted(new Model());
+}
+
+// or
+
+public ActionResult Get()
+{
+ return StatusCode(StatusCodes.Status202Accepted, new Model());
+}
+
+// or
+
+public Model Get()
+{
+ Response.StatusCode = StatusCodes.Status202Accepted;
+ return new Model();
+}
+```
+
+## Affected APIs
+
+- MVC/API controller actions
+
+## See also
+
+- [ActionResult\ type](/aspnet/core/web-api/action-return-types#actionresultt-type)
diff --git a/aspnetcore/breaking-changes/6/adddataannotationsvalidation-obsolete.md b/aspnetcore/breaking-changes/6/adddataannotationsvalidation-obsolete.md
new file mode 100644
index 000000000000..ecb614600225
--- /dev/null
+++ b/aspnetcore/breaking-changes/6/adddataannotationsvalidation-obsolete.md
@@ -0,0 +1,55 @@
+---
+title: "Breaking change: AddDataAnnotationsValidation method obsoleted"
+description: "Learn about the breaking change in ASP.NET Core 6.0 where the AddDataAnnotationsValidation method is replaced with EnableDataAnnotationsValidation."
+ms.date: 04/21/2021
+ms.custom: https://github.com/aspnet/Announcements/issues/458
+---
+# AddDataAnnotationsValidation method made obsolete
+
+The extension method is marked as obsolete starting in ASP.NET Core 6. Developers should use the new extension method `EditContextDataAnnotationsExtensions.EnableDataAnnotationsValidation` instead.
+
+The only difference between these two APIs is their return value:
+
+```csharp
+EditContext AddDataAnnotationsValidation(this EditContext editContext) { ... }
+
+IDisposable EnableDataAnnotationsValidation(this EditContext editContext) { ... }
+```
+
+## Version introduced
+
+ASP.NET Core 6.0
+
+## Old behavior
+
+The older API, , returns its `EditContext` (as a kind of fluent API).
+
+## New behavior
+
+The new API, `EnableDataAnnotationsValidation`, returns an whose disposal can be used to remove the data-annotations validation support from the `EditContext`.
+
+## Reason for change
+
+There are cases where it's desirable to remove the data-annotations validation support after adding it. This was not possible with the older API because there was no place to store the internal event subscriptions. The new API returns an object that holds the state necessary to remove data-annotations validation support on disposal.
+
+## Recommended action
+
+Most applications don't need to be changed. The direct use of these extension methods is a rare and advanced case. If your app uses the `` component instead of calling this method directly, it doesn't need to be changed.
+
+However, if you do call `editContext.AddDataAnnotationsValidation()`, then replace that call with `editContext.EnableDataAnnotationsValidation()`. Optionally, capture the new returned `IDisposable` object and dispose it later if you want to undo the effects of the call.
+
+## Affected APIs
+
+-
+
+
diff --git a/aspnetcore/breaking-changes/6/assemblies-removed-from-shared-framework.md b/aspnetcore/breaking-changes/6/assemblies-removed-from-shared-framework.md
new file mode 100644
index 000000000000..4bcbdc59e61b
--- /dev/null
+++ b/aspnetcore/breaking-changes/6/assemblies-removed-from-shared-framework.md
@@ -0,0 +1,67 @@
+---
+title: "Breaking change: Assemblies removed from Microsoft.AspNetCore.App shared framework"
+description: "Learn about the breaking change in ASP.NET Core 6.0 where some assemblies where removed from the Microsoft.AspNetCore.App shared framework."
+ms.date: 04/02/2021
+ms.custom: https://github.com/aspnet/Announcements/issues/456
+---
+# Assemblies removed from Microsoft.AspNetCore.App shared framework
+
+The following two assemblies were removed from the ASP.NET Core targeting pack:
+
+- System.Security.Permissions
+- System.Windows.Extensions
+
+In addition, the following assemblies were removed from the ASP.NET Core runtime pack:
+
+- Microsoft.Win32.SystemEvents
+- System.Drawing.Common
+- System.Security.Permissions
+- System.Windows.Extensions
+
+## Version introduced
+
+ASP.NET Core 6.0
+
+## Old behavior
+
+Applications could use APIs provided by these libraries by referencing the [Microsoft.AspNetCore.App](/aspnet/core/fundamentals/metapackage-app) shared framework.
+
+## New behavior
+
+If you use APIs from the affected assemblies without having a [PackageReference](/dotnet/core/project-sdk/msbuild-props#packagereference) in your project file, you might see runtime errors. For example, an application that uses reflection to access APIs from one of these assemblies without adding an explicit reference to the package will have runtime errors. The `PackageReference` ensures that the assemblies are present as part of the application output.
+
+For discussion, see .
+
+## Reason for change
+
+This change was introduced to reduce the size of the ASP.NET Core shared framework.
+
+## Recommended action
+
+To continue using these APIs in your project, add a [PackageReference](/dotnet/core/project-sdk/msbuild-props#packagereference). For example:
+
+```xml
+
+```
+
+## Affected APIs
+
+-
+-
+-
+-
+
+
diff --git a/aspnetcore/breaking-changes/6/blazor-eventargstype-property-replaced.md b/aspnetcore/breaking-changes/6/blazor-eventargstype-property-replaced.md
new file mode 100644
index 000000000000..285c645139ca
--- /dev/null
+++ b/aspnetcore/breaking-changes/6/blazor-eventargstype-property-replaced.md
@@ -0,0 +1,51 @@
+---
+title: "Breaking change: Blazor: WebEventDescriptor.EventArgsType property replaced"
+description: "Learn about the breaking change in ASP.NET Core 6.0 where the WebEventDescriptor.EventArgsType property is replaced by the EventName property."
+ms.author: scaddie
+ms.date: 02/24/2021
+ms.custom: https://github.com/aspnet/Announcements/issues/453
+no-loc: [ Blazor ]
+---
+# Blazor: :::no-loc text="WebEventDescriptor.EventArgsType"::: property replaced
+
+The class is part of Blazor's internal protocol for communicating events from JavaScript into .NET. This class isn't typically used by app code, but rather by platform authors.
+
+Starting in ASP.NET Core 6.0, the property on `WebEventDescriptor` is being replaced by a new `EventName` property. This change is unlikely to affect any app code, as it's a low-level platform implementation detail.
+
+## Version introduced
+
+ASP.NET Core 6.0
+
+## Old behavior
+
+In ASP.NET Core 5.0 and earlier, the property `EventArgsType` describes a nonstandard, Blazor-specific category name for groups of DOM event types. For example, the `click` and `mousedown` events were both mapped to an `EventArgsType` value of `mouse`. Similarly, `cut`, `copy`, and `paste` events are mapped to an `EventArgsType` value of `clipboard`. These category names are used to determine the .NET type to use for deserializing the incoming event arguments data.
+
+## New behavior
+
+Starting in ASP.NET Core 6.0, the new property `EventName` only specifies the original event's name. For example, `click`, `mousedown`, `cut`, `copy`, or `paste`. There's no longer a need to supply a Blazor-specific category name. For that reason, the old property `EventArgsType` is removed.
+
+## Reason for change
+
+In pull request [dotnet/aspnetcore#29993](https://github.com/dotnet/aspnetcore/pull/29993), support for custom event arguments classes was introduced. As part of this support, the framework no longer relies on all events fitting into a predefined set of categories. The framework now only needs to know the original event name.
+
+## Recommended action
+
+App code should be unaffected and doesn't need to change.
+
+If building a custom Blazor rendering platform, you may need to update the mechanism for dispatching events into the `Renderer`. Replace any hardcoded rules about event categories with simpler logic that supplies the original, raw event name.
+
+## Affected APIs
+
+
+
+
diff --git a/aspnetcore/breaking-changes/6/blazor-parameter-name-changed-in-method.md b/aspnetcore/breaking-changes/6/blazor-parameter-name-changed-in-method.md
new file mode 100644
index 000000000000..16a03b7ca4d7
--- /dev/null
+++ b/aspnetcore/breaking-changes/6/blazor-parameter-name-changed-in-method.md
@@ -0,0 +1,47 @@
+---
+title: "Breaking change: Blazor: Parameter name changed in RequestImageFileAsync method"
+description: "Learn about the breaking change in ASP.NET Core 6.0 titled Blazor: Parameter name changed in RequestImageFileAsync method"
+no-loc: [ Blazor ]
+ms.author: scaddie
+ms.date: 02/09/2021
+ms.custom: https://github.com/aspnet/Announcements/issues/451
+---
+# Blazor: Parameter name changed in RequestImageFileAsync method
+
+The `RequestImageFileAsync` method's `maxWith` parameter was renamed from `maxWith` to `maxWidth`.
+
+## Version introduced
+
+ASP.NET Core 6.0
+
+## Old behavior
+
+The parameter name is spelled `maxWith`.
+
+## New behavior
+
+The parameter name is spelled `maxWidth`.
+
+## Reason for change
+
+The original parameter name was a typographical error.
+
+## Recommended action
+
+If you're using named parameters in the `RequestImageFile` API, update the `maxWith` parameter name to `maxWidth`. Otherwise, no change is necessary.
+
+## Affected APIs
+
+
+
+
diff --git a/aspnetcore/breaking-changes/6/byte-array-interop.md b/aspnetcore/breaking-changes/6/byte-array-interop.md
new file mode 100644
index 000000000000..d6206f7b6c7e
--- /dev/null
+++ b/aspnetcore/breaking-changes/6/byte-array-interop.md
@@ -0,0 +1,71 @@
+---
+title: "Breaking change: Blazor: Byte Array Interop"
+description: "Learn about the breaking change in ASP.NET Core 6.0 titled Blazor: Byte Array Interop"
+no-loc: [ Blazor ]
+ms.date: 06/21/2021
+ms.custom: https://github.com/dotnet/Announcements/issues/187
+---
+# Blazor: Byte-array interop
+
+Blazor now supports optimized byte-array interop, which avoids encoding and decoding byte-arrays into Base64 and facilitates a more efficient interop process. This applies to both Blazor Server and Blazor WebAssembly.
+
+## Version introduced
+
+ASP.NET Core 6.0
+
+## Receive byte array in JavaScript from .NET
+
+### Old behavior
+
+```typescript
+function receivesByteArray(data) {
+ // Previously, data was a Base64-encoded string representing the byte array.
+}
+```
+
+### New behavior
+
+```typescript
+function receivesByteArray(data) {
+ // Data is a Uint8Array (no longer requires processing the Base64 encoding).
+}
+```
+
+## Reason for change
+
+This change was made to create a more efficient interop mechanism for byte arrays.
+
+## Recommended action
+
+### Receive byte array in JavaScript from .NET
+
+Consider this .NET interop, where you call into JavaScript passing a byte array:
+
+```csharp
+var bytes = new byte[] { 1, 5, 7 };
+await _jsRuntime.InvokeVoidAsync("receivesByteArray", bytes);
+```
+
+In the preceding code example, you'd treat the incoming parameter in JavaScript as a byte array instead of a Base64-encoded string.
+
+### Return byte array from JavaScript to .NET
+
+If .NET expects a `byte[]`, JavaScript _should_ provide a `Uint8Array`. It's still possible to provide a Base64-encoded array using `btoa`, however that is less performant.
+
+For example, if you have the following code, then you _should_ provide a `Uint8Array` from JavaScript that's _not_ Base64-encoded:
+
+```csharp
+var bytes = await _jsRuntime.InvokeAsync("someJSMethodReturningAByteArray");
+```
+
+
diff --git a/aspnetcore/breaking-changes/6/clientcertificate-doesnt-trigger-renegotiation.md b/aspnetcore/breaking-changes/6/clientcertificate-doesnt-trigger-renegotiation.md
new file mode 100644
index 000000000000..57b4d7dec262
--- /dev/null
+++ b/aspnetcore/breaking-changes/6/clientcertificate-doesnt-trigger-renegotiation.md
@@ -0,0 +1,60 @@
+---
+title: "Breaking change: ClientCertificate property no longer triggers renegotiation for HttpSys"
+description: "Learn about the breaking change in ASP.NET Core 6.0 where the ClientCertificate property no longer triggers renegotiation for HttpSys."
+ms.date: 07/20/2021
+ms.custom: https://github.com/aspnet/Announcements/issues/466
+no-loc: [ Kestrel ]
+---
+# ClientCertificate property no longer triggers renegotiation for HttpSys
+
+The [`HttpContext.Connection.ClientCertificate`](xref:Microsoft.AspNetCore.Http.ConnectionInfo.ClientCertificate?displayProperty=nameWithType) property no longer triggers TLS renegotiations for HttpSys.
+
+## Version introduced
+
+ASP.NET Core 6.0
+
+### Old behavior
+
+Setting `HttpSysOptions.ClientCertificateMethod = ClientCertificateMethod.AllowRenegotiation` allowed renegotiation to be triggered by both `HttpContext.Connection.ClientCertificate` and `HttpContext.Connection.GetClientCertificateAsync`.
+
+### New behavior
+
+Setting `HttpSysOptions.ClientCertificateMethod = ClientCertificateMethod.AllowRenegotiation` allows renegotiation to be triggered only by `HttpContext.Connection.GetClientCertificateAsync`. `HttpContext.Connection.ClientCertificate` returns the current certificate if available, but does not renegotiate with the client to request the certificate.
+
+## Reason for change
+
+When implementing the same features for Kestrel, it became clear that applications need to be able to check the state of the client certificate before triggering a renegotiation. For issues like the request body conflicting with the renegotiation, checking the state enables the following usage pattern to deal with the issue:
+
+```csharp
+if (connection.ClientCertificate == null)
+{
+ await BufferRequestBodyAsync();
+ await connection.GetClientCertificateAsync();
+}
+```
+
+## Recommended action
+
+Apps that use delayed client-certificate negotiation should call to trigger renegotiation.
+
+## Affected APIs
+
+-
+-
+-
+
+## See also
+
+- [dotnet/aspnetcore issue number 34124](https://github.com/dotnet/aspnetcore/issues/34124)
+
+
diff --git a/aspnetcore/breaking-changes/6/endpointname-metadata.md b/aspnetcore/breaking-changes/6/endpointname-metadata.md
new file mode 100644
index 000000000000..f199bb817391
--- /dev/null
+++ b/aspnetcore/breaking-changes/6/endpointname-metadata.md
@@ -0,0 +1,49 @@
+---
+title: "Breaking change: EndpointName metadata no longer automatically set"
+description: "Learn about the breaking change in ASP.NET Core 6.0 where EndpointName metadata is no longer automatically set for minimal endpoints."
+ms.date: 10/18/2021
+ms.custom: https://github.com/aspnet/Announcements/issues/473
+---
+# EndpointName metadata not set automatically
+
+Behavior that was introduced in .NET 6 RC 1 to automatically set `IEndpointNameMetadata` for endpoints has been reverted. `IEndpointNameMetadata` is no longer set automatically to avoid issues with duplicate endpoint names.
+
+## Version introduced
+
+ASP.NET Core 6 RC 2
+
+## Previous behavior
+
+In ASP.NET Core 6 RC 1, `IEndpointNameMetadata` was automatically set for endpoints that referenced a method group. For example, the following code produced an endpoint for `/foo` with `EndpointName` set to `GetFoo`.
+
+```csharp
+app.MapGet("/foo", GetFoo);
+```
+
+## New behavior
+
+Starting in ASP.NET Core 6 RC 2, `IEndpointNameMetadata` is not automatically set. The following code does not generate any `IEndpointNameMetadata`.
+
+```csharp
+app.MapGet("/foo", GetFoo);
+```
+
+## Type of breaking change
+
+This change can affect [source compatibility](/dotnet/core/compatibility/categories#source-compatibility).
+
+## Reason for change
+
+The behavior of automatically setting endpoint name metadata was not robust and resulted in issues where the same name was set for different endpoints. For more information, see [dotnet/aspnetcore#36487](https://github.com/dotnet/aspnetcore/issues/36487).
+
+## Recommended action
+
+We recommend that you manually set `IEndpointNameMetadata` using the `WithName` extension method to set the metadata.
+
+```csharp
+app.MapGet("/foo", GetFoo).WithName("GetFoo");
+```
+
+## Affected APIs
+
+N/A
diff --git a/aspnetcore/breaking-changes/6/iasyncenumerable-not-buffered-by-mvc.md b/aspnetcore/breaking-changes/6/iasyncenumerable-not-buffered-by-mvc.md
new file mode 100644
index 000000000000..1a1896e1b2f7
--- /dev/null
+++ b/aspnetcore/breaking-changes/6/iasyncenumerable-not-buffered-by-mvc.md
@@ -0,0 +1,59 @@
+---
+title: "Breaking change: MVC no longer buffers IAsyncEnumerable types when using System.Text.Json"
+description: "Learn about the breaking change in ASP.NET Core 6.0 where MVC no longer buffers IAsyncEnumerable return types when formatting using System.Text.Json."
+ms.date: 05/17/2021
+ms.custom: https://github.com/aspnet/Announcements/issues/463
+---
+# MVC doesn't buffer IAsyncEnumerable types when using System.Text.Json
+
+In ASP.NET Core 5, MVC added support for output formatting types by buffering the sequence in memory and formatting the buffered collection. In ASP.NET Core 6, when formatting using , MVC no longer buffers instances. Instead, MVC relies on the support that added for these types.
+
+In most cases, the absence of buffering would not be observable by the application. However, some scenarios may have inadvertently relied on the buffering semantics to correctly serialize. For example, returning an that's backed by an Entity Framework query on a type with lazy-loaded properties can result in concurrent query execution, which might not be supported by the provider.
+
+This change does not affect output formatting using Newtonsoft.Json or with XML-based formatters.
+
+## Version introduced
+
+ASP.NET Core 6.0
+
+## Old behavior
+
+ instances returned from an MVC action as a value to be formatted using or a are buffered before being serialized as a synchronous collection.
+
+## New behavior
+
+When formatting using , MVC no longer buffers instances.
+
+## Reason for change
+
+ added support for streaming types. This allows for a smaller memory footprint during serialization.
+
+## Recommended action
+
+If your application requires buffering, consider manually buffering the object:
+
+```csharp
+// Before
+public IActionResult Get()
+{
+ return Ok(dbContext.Blogs);
+}
+
+// After
+public async Task Get()
+{
+ return Ok(await dbContext.Blogs.ToListAsync());
+}
+```
+
+
diff --git a/aspnetcore/breaking-changes/6/identity-bootstrap4-to-5.md b/aspnetcore/breaking-changes/6/identity-bootstrap4-to-5.md
new file mode 100644
index 000000000000..6d180d82f240
--- /dev/null
+++ b/aspnetcore/breaking-changes/6/identity-bootstrap4-to-5.md
@@ -0,0 +1,52 @@
+---
+title: "Breaking change: Default version of Bootstrap used with Identity now 5"
+description: "Learn about the breaking change in ASP.NET Core 6.0 where the default version of Bootstrap used with Identity changes from 4 to 5."
+ms.date: 02/15/2022
+---
+# Identity: Default Bootstrap version of UI changed
+
+Starting in ASP.NET Core 6.0, Identity UI defaults to using [version 5 of Bootstrap](https://getbootstrap.com/docs/5.0/getting-started/introduction/). ASP.NET Core 3.0 to 5.0 used version 4 of Bootstrap.
+
+## Version introduced
+
+ASP.NET Core 6.0
+
+## Behavior
+
+ calls the internal private method [TryResolveUIFramework](https://github.com/dotnet/aspnetcore/blob/v6.0.2/src/Identity/UI/src/IdentityBuilderUIExtensions.cs#L82-L102). `TryResolveUIFramework` reads the from the application assembly. The `UIFramework` version defaults to:
+
+* Bootstrap 5 for the .NET 6 SDK
+* Bootstrap 4 for the .NET Core 3.1 and .NET 5 SDK
+
+Template-created ASP.NET Core 3.1 and 5.0 apps contain Bootstrap 4 in *wwwroot\lib\bootstrap*. Template-created ASP.NET Core 6 apps use Bootstrap 5. When an ASP.NET Core 3.1 or 5.0 app is migrated to .NET 6, the application detects `UIFramework` version 5, while *wwwroot\lib\bootstrap* contains version 4. This version mismatch renders the Identity templates incorrectly.
+
+## Reason for change
+
+Bootstrap 5 was released during the ASP.NET Core 6.0 timeframe.
+
+## Recommended action
+
+Apps that are impacted by this change use the default Identity UI and have added it in `Startup.ConfigureServices` as shown in the following code:
+
+```csharp
+services.AddDefaultIdentity()
+```
+
+Take one of the following actions:
+
+* Add the MSBuild property `IdentityUIFrameworkVersion` in the project file and specify Bootstrap 4:
+
+ ```xml
+
+ net6.0
+ Bootstrap4
+
+ ```
+
+ The preceding markup sets the `UIFramework` version to Bootstrap 4, the same Bootstrap version as used in ASP.NET Core 3.1 and 5.0.
+
+* Rename or delete the *wwwroot\lib\bootstrap* folder and replace it with the *wwwroot\lib\bootstrap* folder from an ASP.NET Core 6 template-generated app. The Identity templates work with this change but apps using Bootstrap may need to refer to the [Bootstrap 5 migration guide](https://getbootstrap.com/docs/5.0/migration/).
+
+## Affected APIs
+
+
diff --git a/aspnetcore/breaking-changes/6/kestrel-log-message-attributes-changed.md b/aspnetcore/breaking-changes/6/kestrel-log-message-attributes-changed.md
new file mode 100644
index 000000000000..aaa97dc917b8
--- /dev/null
+++ b/aspnetcore/breaking-changes/6/kestrel-log-message-attributes-changed.md
@@ -0,0 +1,52 @@
+---
+title: "Breaking change: Kestrel: Log message attributes changed"
+description: "Learn about the breaking change in ASP.NET Core 6.0 titled Kestrel: Log message attributes changed"
+ms.author: scaddie
+ms.date: 02/01/2021
+ms.custom: https://github.com/aspnet/Announcements/issues/447
+---
+# Kestrel: Log message attributes changed
+
+Kestrel log messages have associated IDs and names. These attributes uniquely identify different kinds of log messages. Some of those IDs and names were incorrectly duplicated. This duplication problem is fixed in ASP.NET Core 6.0.
+
+## Version introduced
+
+ASP.NET Core 6.0
+
+## Old behavior
+
+The following table shows the state of the affected log messages before ASP.NET Core 6.0.
+
+| Message description | Name | ID |
+|---------------------------------------|-------------------------|----|
+| HTTP/2 connection closed log messages | `Http2ConnectionClosed` | 36 |
+| HTTP/2 frame sending log messages | `Http2FrameReceived` | 37 |
+
+## New behavior
+
+The following table shows the state of the affected log messages in ASP.NET Core 6.0.
+
+| Message description | Name | ID |
+|---------------------------------------|-------------------------|----|
+| HTTP/2 connection closed log messages | `Http2ConnectionClosed` | 48 |
+| HTTP/2 frame sending log messages | `Http2FrameSending` | 49 |
+
+## Reason for change
+
+Log IDs and names should be unique so different message types can be identified.
+
+## Recommended action
+
+If you have code or configuration that references the old IDs and names, update those references to use the new IDs and names.
+
+
diff --git a/aspnetcore/breaking-changes/6/messagepack-library-change.md b/aspnetcore/breaking-changes/6/messagepack-library-change.md
new file mode 100644
index 000000000000..fb06cb2d6597
--- /dev/null
+++ b/aspnetcore/breaking-changes/6/messagepack-library-change.md
@@ -0,0 +1,65 @@
+---
+title: "Breaking change: Changed MessagePack library in signalr-protocol-msgpack package"
+description: "Learn about the breaking change in ASP.NET Core 6.0 where the MessagePack library was changed and two options were removed in the @microsoft/signalr-protocol-msgpack package."
+ms.date: 04/07/2021
+ms.custom: https://github.com/aspnet/Announcements/issues/454
+---
+# Changed MessagePack library in @microsoft/signalr-protocol-msgpack
+
+The [@microsoft/signalr-protocol-msgpack](https://www.npmjs.com/package/@microsoft/signalr-protocol-msgpack) npm package now references `@msgpack/msgpack` instead of `msgpack5`. Additionally, the available options that can optionally be passed into the `MessagePackHubProtocol` have changed. The `MessagePackOptions.disableTimestampEncoding` and `MessagePackOptions.forceFloat64` properties were removed, and some new options were added.
+
+For discussion, see .
+
+## Version introduced
+
+ASP.NET Core 6.0
+
+## Old behavior
+
+In previous versions, you must include three script references to use the [MessagePack Hub Protocol](/aspnet/core/signalr/messagepackhubprotocol) in the browser:
+
+```html
+
+
+
+```
+
+## New behavior
+
+Starting in ASP.NET Core 6, you only need two script references to use the [MessagePack Hub Protocol](/aspnet/core/signalr/messagepackhubprotocol) in the browser:
+
+```html
+
+
+```
+
+Instead of the `msgpack5` package, the `@msgpack/msgpack` package is downloaded to your *node_modules* directory if you want to use it directly in your app.
+
+Finally, `MessagePackOptions` has new, additional properties, and the `disableTimestampEncoding` and `forceFloat64` properties are removed.
+
+## Reason for change
+
+This change was made to reduce asset size, make it simpler to consume the package, and add more customizability.
+
+## Recommended action
+
+If you were previously using `msgpack5` in your app, you'll need to add a direct reference to the library in your *package.json* file.
+
+## Affected APIs
+
+The following APIs were removed:
+
+- `MessagePackOptions.disableTimestampEncoding`
+- `MessagePackOptions.forceFloat64`
+
+
diff --git a/aspnetcore/breaking-changes/6/microsoft-aspnetcore-http-features-package-split.md b/aspnetcore/breaking-changes/6/microsoft-aspnetcore-http-features-package-split.md
new file mode 100644
index 000000000000..945a73e598ae
--- /dev/null
+++ b/aspnetcore/breaking-changes/6/microsoft-aspnetcore-http-features-package-split.md
@@ -0,0 +1,88 @@
+---
+title: "Breaking change: Microsoft.AspNetCore.Http.Features split up"
+description: "Learn about the breaking change in ASP.NET Core 6.0 where the Microsoft.AspNetCore.Http.Features package has been split, and no longer ships as a package."
+ms.date: 05/06/2021
+ms.custom: https://github.com/aspnet/Announcements/issues/461
+---
+# Microsoft.AspNetCore.Http.Features split
+
+Microsoft.AspNetCore.Http.Features has been split into the following two assemblies:
+
+- Microsoft.AspNetCore.Http.Features
+- Microsoft.Extensions.Features
+
+For discussion, see GitHub issue [dotnet/aspnetcore#32307](https://github.com/dotnet/aspnetcore/issues/32307).
+
+## Version introduced
+
+ASP.NET Core 6.0
+
+## Old behavior
+
+Microsoft.AspNetCore.Http.Features 5.0 shipped both in the ASP.NET shared framework and as a NuGet package. Microsoft.AspNetCore.Http.Features 5.0 targeted .NET 4.6.1, .NET Standard 2.0, and .NET 5.
+
+## New behavior
+
+Microsoft.AspNetCore.Http.Features 6.0 ships only in the ASP.NET shared framework, not as a NuGet package. It targets .NET 6 only.
+
+Microsoft.Extensions.Features 6.0 ships in both the ASP.NET shared framework and as a NuGet package. It targets .NET 4.6.1, .NET Standard 2.0, and .NET 6.
+
+The following types have been moved to the new Microsoft.Extensions.Features assembly:
+
+-
+-
+-
+-
+
+These types are still in the `Microsoft.AspNetCore.Http.Features` namespace, and type forwards have been added for compatibility.
+
+## Reason for change
+
+This change was introduced for two reasons:
+
+- Allows the core types to be shared more broadly across components.
+- Allows the remaining Http-specific components in Microsoft.AspNetCore.Http.Features to take advantage of new runtime and language features.
+
+## Recommended action
+
+When upgrading to ASP.NET Core 6.0, remove any packages references for Microsoft.AspNetCore.Http.Features. Add a package reference for Microsoft.Extensions.Features only if required.
+
+For class libraries that need to consume the types from Microsoft.AspNetCore.Http.Features, add a `FrameworkReference` item instead:
+
+```xml
+
+
+
+```
+
+For more information about adding the framework reference, see [Use the ASP.NET Core shared framework](/aspnet/core/fundamentals/target-aspnetcore?#use-the-aspnet-core-shared-framework).
+
+Libraries with out of date references may encounter a or the following error:
+
+**Error CS0433 The type 'IFeatureCollection' exists in both 'Microsoft.AspNetCore.Http.Features, Version=5.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60' and 'Microsoft.Extensions.Features, Version=6.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'**
+
+To resolve the error, add a `FrameworkReference` to Microsoft.AspNetCore.App to any of the affected projects.
+
+For questions, see [dotnet/aspnetcore#32307](https://github.com/dotnet/aspnetcore/issues/32307).
+
+## Affected APIs
+
+-
+-
+-
+-
+
+
diff --git a/aspnetcore/breaking-changes/6/middleware-ambiguous-https-ports-exception.md b/aspnetcore/breaking-changes/6/middleware-ambiguous-https-ports-exception.md
new file mode 100644
index 000000000000..2a50d4941870
--- /dev/null
+++ b/aspnetcore/breaking-changes/6/middleware-ambiguous-https-ports-exception.md
@@ -0,0 +1,61 @@
+---
+title: "Breaking change: Middleware: HTTPS Redirection Middleware throws exception on ambiguous HTTPS ports"
+description: "Learn about the breaking change in ASP.NET Core 6.0 titled Middleware: HTTPS Redirection Middleware throws exception on ambiguous HTTPS ports"
+ms.author: scaddie
+ms.date: 02/04/2021
+ms.custom: https://github.com/aspnet/Announcements/issues/448
+---
+# Middleware: HTTPS Redirection Middleware throws exception on ambiguous HTTPS ports
+
+In ASP.NET Core 6.0, the [HTTPS Redirection Middleware](xref:Microsoft.AspNetCore.Builder.HttpsPolicyBuilderExtensions.UseHttpsRedirection%2A) throws an exception of type when it finds multiple HTTPS ports in the server configuration. The exception's message contains the text "Cannot determine the https port from IServerAddressesFeature, multiple values were found. Set the desired port explicitly on HttpsRedirectionOptions.HttpsPort."
+
+For discussion, see GitHub issue [dotnet/aspnetcore#29222](https://github.com/dotnet/aspnetcore/issues/29222).
+
+## Version introduced
+
+ASP.NET Core 6.0
+
+## Old behavior
+
+When the HTTPS Redirection Middleware isn't explicitly configured with a port, it searches during the first request to determine the HTTPS port to which it should redirect.
+
+If there are no HTTPS ports or multiple distinct ports, it's unclear which port should be used. The middleware logs a warning and disables itself. HTTP requests are processed normally.
+
+## New behavior
+
+When the HTTPS Redirection Middleware isn't explicitly configured with a port, it searches `IServerAddressesFeature` during the first request to determine the HTTPS port to which it should redirect.
+
+If there are no HTTPS ports, the middleware still logs a warning and disables itself. HTTP requests are processed normally. This behavior supports:
+
+* Development scenarios without HTTPS.
+* Hosted scenarios in which TLS is terminated before reaching the server.
+
+If there are multiple distinct ports, it's unclear which port should be used. The middleware throws an exception and fails the HTTP request.
+
+## Reason for change
+
+This change prevents potentially sensitive data from being served over unencrypted HTTP connections when HTTPS is known to be available.
+
+## Recommended action
+
+To enable HTTPS redirection when the server has multiple distinct HTTPS ports, you must specify one port in the configuration. For more information, see [Port configuration](/aspnet/core/security/enforcing-ssl?view=aspnetcore-5.0&preserve-view=true#port-configuration).
+
+If you don't need the HTTPS Redirection Middleware in your app, remove `UseHttpsRedirection` from *Startup.cs*.
+
+If you need to select the correct HTTPS port dynamically, provide feedback in GitHub issue [dotnet/aspnetcore#21291](https://github.com/dotnet/aspnetcore/issues/21291).
+
+## Affected APIs
+
+
+
+
diff --git a/aspnetcore/breaking-changes/6/middleware-new-use-overload.md b/aspnetcore/breaking-changes/6/middleware-new-use-overload.md
new file mode 100644
index 000000000000..a72911b61169
--- /dev/null
+++ b/aspnetcore/breaking-changes/6/middleware-new-use-overload.md
@@ -0,0 +1,83 @@
+---
+title: "Breaking change: Middleware: New Use overload"
+description: "Learn about the breaking change in ASP.NET Core 6.0 where a new overload of Use middleware was introduced."
+ms.date: 05/06/2021
+ms.custom: https://github.com/aspnet/Announcements/issues/461
+---
+# Middleware: New Use overload
+
+A new overload of `app.Use` has been introduced. If you call `app.Use` but never call the `next` middleware, you'll now get compiler error CS0121:
+
+**The call is ambiguous between the following methods or properties: 'UseExtensions.Use(IApplicationBuilder, Func)' and 'UseExtensions.Use(IApplicationBuilder, Func)'**
+
+To resolve the error, use `app.Run` instead of `app.Use`.
+
+For discussion, see GitHub issue [dotnet/aspnetcore#32020](https://github.com/dotnet/aspnetcore/issues/32020).
+
+## Version introduced
+
+ASP.NET Core 6.0
+
+## Old behavior
+
+```csharp
+app.Use(async (context, next) =>
+{
+ await next();
+});
+```
+
+or
+
+```csharp
+app.Use(async (context, next) =>
+{
+ await SomeAsyncWork();
+ // next not called...
+});
+```
+
+## New behavior
+
+You can now pass `context` to the `next` delegate:
+
+```csharp
+app.Use(async (context, next) =>
+{
+ await next(context);
+});
+```
+
+Use `app.Run` when your middleware never calls `next`:
+
+```csharp
+app.Run(async (context) =>
+{
+ await SomeAsyncWork();
+ // next never called
+});
+```
+
+## Reason for change
+
+The previous `Use` method allocates two objects per request. The new overload avoids these allocations with a small change to how you invoke the `next` middleware.
+
+## Recommended action
+
+If you get a compile error, it means you are calling `app.Use` without using the `next` delegate. Switch to `app.Run` to fix the error.
+
+## Affected APIs
+
+None.
+
+
diff --git a/aspnetcore/breaking-changes/6/nullable-reference-type-annotations-changed.md b/aspnetcore/breaking-changes/6/nullable-reference-type-annotations-changed.md
new file mode 100644
index 000000000000..ab5866f72425
--- /dev/null
+++ b/aspnetcore/breaking-changes/6/nullable-reference-type-annotations-changed.md
@@ -0,0 +1,236 @@
+---
+title: "Breaking change: Nullable reference type annotations changed"
+description: "Learn about the breaking change in ASP.NET Core 6.0 titled Nullable reference type annotations changed"
+ms.author: scaddie
+ms.date: 02/24/2021
+ms.custom: https://github.com/aspnet/Announcements/issues/444
+---
+# Nullable reference type annotations changed
+
+Starting in ASP.NET Core 5.0, nullability annotations have been applied to parts of the code. From the outset of this effort, [mistakes were expected](https://github.com/dotnet/runtime/blob/main/docs/coding-guidelines/api-guidelines/nullability.md#breaking-change-guidance) in these annotations and fixes would need to be made. In ASP.NET Core 6.0, some previously applied annotations are being updated. Some of these changes are considered source breaking changes. The changes lead to the APIs being incompatible or more restrictive. The updated APIs may result in build-time warnings when used in projects that have nullable reference types enabled.
+
+For discussion, see GitHub issue [dotnet/aspnetcore#27564](https://github.com/dotnet/aspnetcore/issues/27564).
+
+## Version introduced
+
+ASP.NET Core 6.0
+
+## Old behavior
+
+The affected APIs have incorrect nullable reference type annotations. Build warnings are either absent or incorrect.
+
+## New behavior
+
+New build warnings are produced. Incorrect build warnings are no longer produced for the affected APIs.
+
+## Reason for change
+
+Through feedback and further testing, the nullable annotations for the affected APIs were determined to be inaccurate. The updated annotations now correctly represent the nullability contracts for the APIs.
+
+## Recommended action
+
+Update code calling these APIs to reflect the revised nullability contracts.
+
+## Affected APIs
+
+*
+*
+*
+*
+*
+*
+*
+*
+*
+*
+*
+*
+*
+*
+*
+*
+*
+*
+*
+*
+*
+*
+*
+*
+*
+*
+*
+*
+*
+*
+*
+*
+*
+*
+*
+*
+*
+*
+* >
+*
+*
+*
+*