Merge pull request #35272 from dotnet/main

Merge to Live

Author: Rick-Anderson

aspnetcore/blazor/security/index.md

@@ -96,7 +96,7 @@ The authentication context is only established when the app starts, which is whe
 
 If the app must capture users for custom services or react to updates to the user, see <xref:blazor/security/additional-scenarios#circuit-handler-to-capture-users-for-custom-services>.
 
-Blazor differs from a traditional server-rendered web apps that make new HTTP requests with cookies on every page navigation. Authentication is checked during navigation events. However, cookies aren't involved. Cookies are only sent when making an HTTP request to a server, which isn't what happens when the user navigates in a Blazor app. During navigation, the user's authentication state is checked within the Blazor circuit, which you can update at any time on the server using the [`RevalidatingAuthenticationStateProvider` abstraction](#additional-security-abstractions).
+Blazor differs from traditional server-rendered web apps that make new HTTP requests with cookies on every page navigation. Authentication is checked during navigation events. However, cookies aren't involved. Cookies are only sent when making an HTTP request to a server, which isn't what happens when the user navigates in a Blazor app. During navigation, the user's authentication state is checked within the Blazor circuit, which you can update at any time on the server using the [`RevalidatingAuthenticationStateProvider` abstraction](#additional-security-abstractions).
 
 > [!IMPORTANT]
 > Implementing a custom `NavigationManager` to achieve authentication validation during navigation isn't recommended. If the app must execute custom authentication state logic during navigation, use a [custom `AuthenticationStateProvider`](xref:blazor/security/authentication-state#implement-a-custom-authenticationstateprovider).

aspnetcore/data/ef-mvc/sort-filter-page.md

@@ -88,7 +88,7 @@ You've added a `searchString` parameter to the `Index` method. The search string
 > [!NOTE]
 > Here you are calling the `Where` method on an `IQueryable` object, and the filter will be processed on the server. In some scenarios you might be calling the `Where` method as an extension method on an in-memory collection. (For example, suppose you change the reference to `_context.Students` so that instead of an EF `DbSet` it references a repository method that returns an `IEnumerable` collection.) The result would normally be the same but in some cases may be different.
 >
->For example, the .NET Framework implementation of the `Contains` method performs a case-sensitive comparison by default, but in SQL Server this is determined by the collation setting of the SQL Server instance. That setting defaults to case-insensitive. You could call the `ToUpper` method to make the test explicitly case-insensitive:  *Where(s => s.LastName.ToUpper().Contains(searchString.ToUpper())*. That would ensure that results stay the same if you change the code later to use a repository which returns   an `IEnumerable` collection instead of an `IQueryable` object. (When you call the `Contains` method on an `IEnumerable` collection, you get the .NET Framework implementation; when you call it on an `IQueryable` object, you get the database provider implementation.) However, there's a performance penalty for this solution. The `ToUpper` code would put a function in the WHERE clause of the TSQL SELECT statement. That would prevent the optimizer from using an index. Given that SQL is mostly installed as case-insensitive, it's best to avoid the `ToUpper` code until you migrate to a case-sensitive data store.
+>For example, the .NET Framework implementation of the `Contains` method performs a case-sensitive comparison by default, but in SQL Server this is determined by the collation setting of the SQL Server instance. That setting defaults to case-insensitive. You could call the `ToUpper` method to make the test explicitly case-insensitive:  *Where(s => s.LastName.ToUpper().Contains(searchString.ToUpper())*. That would ensure that results stay the same if you change the code later to use a repository which returns   an `IEnumerable` collection instead of an `IQueryable` object. (When you call the `Contains` method on an `IEnumerable` collection, you get the .NET Framework implementation; when you call it on an `IQueryable` object, you get the database provider implementation.) However, there's a performance penalty for this solution. The `ToUpper` code would put a function in the WHERE clause of the TSQL SELECT statement. That would prevent the optimizer from using an index. Given that SQL is mostly installed as case-insensitive, it's best to avoid the `ToUpper` code until you migrate to a case-insensitive data store.
 
 ### Add a Search Box to the Student Index View
 

aspnetcore/fundamentals/configuration/options.md

@@ -5,7 +5,7 @@ description: Discover how to use the options pattern to represent groups of rela
 monikerRange: '>= aspnetcore-3.1'
 ms.author: tdykstra
 ms.custom: mvc
-ms.date: 01/13/2022
+ms.date: 04/19/2025
 uid: fundamentals/configuration/options
 --- 
 # Options pattern in ASP.NET Core
@@ -108,6 +108,22 @@ In the preceding code, by default, changes to the JSON configuration file after
 
 <a name="named"></a>
 
+## Specify a custom key name for a configuration property using `ConfigurationKeyName`
+
+By default, the property names of the options class are used as the key name in the configuration source. If the property name is `Title`, the key name in the configuration is `Title` as well.
+
+When the names differentiate, you can use the [`ConfigurationKeyName` attribute](xref:Microsoft.Extensions.Configuration.ConfigurationKeyNameAttribute) to specify the key name in the configuration source. Using this technique, you can map a property in the configuration to one in your code with a different name. 
+
+This is useful when the property name in the configuration source isn't a valid C# identifier or when you want to use a different name in your code.
+
+For example, consider the following options class:
+
+:::code language="csharp" source="~/fundamentals/configuration/options/samples/6.x/OptionsSample/Models/PositionOptionsWithConfigurationKeyName.cs" id="snippet":::
+
+The `Title` and `Name` class properties are bound to the `position-title` and `position-name` from the following `appsettings.json` file:
+
+:::code language="json" source="~/fundamentals/configuration/options/samples/6.x/OptionsSample/appsettings.KN.json":::
+
 ## Named options support using IConfigureNamedOptions
 
 Named options:

aspnetcore/fundamentals/configuration/options/samples/6.x/OptionsSample/Models/PositionOptionsWithConfigurationKeyName.cs

@@ -0,0 +1,15 @@
+namespace SampleApp.Models
+{
+    #region snippet
+    public class PositionOptionsWithConfigurationKeyName
+    {
+        public const string Position = "Position";
+
+        [ConfigurationKeyName("position-title")]
+        public string Title { get; set; } = string.Empty;
+
+        [ConfigurationKeyName("position-name")]
+        public string Name { get; set; } = string.Empty;
+    }
+    #endregion
+}

aspnetcore/fundamentals/configuration/options/samples/6.x/OptionsSample/appsettings.KN.json

@@ -0,0 +1,6 @@
+{
+  "Position": {
+    "position-title": "Editor",
+    "position-name": "Joe Smith"
+  }
+}

aspnetcore/grpc/interceptors.md

@@ -35,7 +35,7 @@ gRPC client interceptors intercept outgoing RPC invocations. They provide access
 
 `Interceptor` methods to override for client:
 
-* `BlockingUnaryCall`: Intercepts a blocking invocation of an unary RPC.
+* `BlockingUnaryCall`: Intercepts a blocking invocation of a unary RPC.
 * `AsyncUnaryCall`: Intercepts an asynchronous invocation of an unary RPC.
 * `AsyncClientStreamingCall`: Intercepts an asynchronous invocation of a client-streaming RPC.
 * `AsyncServerStreamingCall`: Intercepts an asynchronous invocation of a server-streaming RPC.