Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
En este artículo se resaltan los cambios más significativos de ASP.NET Core en .NET 11 con vínculos a la documentación pertinente.
Este artículo se actualizará a medida que se publiquen nuevas versiones preliminares.
Blazor
En esta sección se describen las nuevas características de Blazor.
Nuevo DisplayName componente y compatibilidad con los atributos [Display] y [DisplayName]
El DisplayName componente se puede usar para mostrar los nombres de propiedad de los atributos de metadatos:
[Required, DisplayName("Production Date")]
public DateTime ProductionDate { get; set; }
Se admite el [Display] atributo en la propiedad de clase de modelo:
[Required, Display(Name = "Production Date")]
public DateTime ProductionDate { get; set; }
De los dos enfoques, se recomienda el [Display] atributo , lo que hace que haya propiedades adicionales disponibles. El [Display] atributo también permite asignar un tipo de recurso para la localización. Cuando ambos atributos están presentes, [Display] tiene prioridad sobre [DisplayName]. Si ninguno de los atributos está presente, el componente vuelve al nombre de la propiedad.
Use el DisplayName componente en etiquetas o encabezados de tabla:
<label>
<DisplayName For="@(() => Model!.ProductionDate)" />
<InputDate @bind-Value="Model!.ProductionDate" />
</label>
Blazor El formato de opciones de inicio de script web ahora es compatible para scripts de Blazor Server y Blazor WebAssembly
El objeto de opciones del script (Blazor Web App) (blazor.web.js) pasado a Blazor.start() utiliza el formato siguiente a partir de la versión .NET 8:
Blazor.start({
ssr: { ... },
circuit: { ... },
webAssembly: { ... },
});
Ahora, los Blazor Server scripts (blazor.server.js) y Blazor WebAssembly (blazor.webassembly.js) pueden usar el mismo formato de opciones.
En el ejemplo siguiente se muestra el formato de opciones anteriores, que sigue siendo compatible:
Blazor.start({
loadBootResource: function (...) {
...
},
});
El formato de las opciones recién admitidas para el ejemplo anterior:
Blazor.start({
webAssembly: {
loadBootResource: function (...) {
...
},
},
});
Para obtener más información, vea Inicio de Blazor de ASP.NET Core.
Nuevo componente de BasePath
Blazor Web Apps puede usar el nuevo componente BasePath (<BasePath />) para procesar automáticamente la etiqueta HTML de la ruta de acceso base de la aplicación (<base href>). Para obtener más información, consulte ruta de acceso base de la aplicación ASP.NET CoreBlazor.
Controlador de eventos en línea JS eliminado del componente NavMenu
El controlador de eventos insertado JS que alterna la presentación de vínculos de navegación ya no está presente en el componente NavMenu de la plantilla de proyecto Blazor Web App. Las aplicaciones generadas a partir de la plantilla de proyecto ahora usan un enfoque de módulo colocado JS para mostrar u ocultar la barra de navegación en la página representada. El nuevo enfoque mejora el cumplimiento de la directiva de seguridad de contenido (CSP) porque no requiere que el CSP incluya un hash no seguro para el elemento insertado JS.
Para migrar una aplicación existente a .NET 11, incluida la adopción del nuevo JS enfoque de módulo para el interruptor de la barra de navegación, consulte Migración de ASP.NET Core en .NET 10 a ASP.NET Core en .NET 11.
NavigateTo y NavLink ofrecen soporte para la navegación relativa
El nuevo RelativeToCurrentUri parámetro (valor predeterminado: false) para NavigationManager.NavigateTo y el componente NavLink permite navegar a los URIs relativos a la ruta de acceso de la página actual en lugar del URI base de la aplicación.
Tenga en cuenta los siguientes puntos de conexión anidados:
/docs/getting-started/installation/configuration
Cuando el URI del navegador es /docs/getting-started/installation y quiere dirigir al usuario a /docs/getting-started/configuration, NavigateTo("/configuration") se redirige a la raíz de aplicación en /configuration en lugar de la ruta de acceso relativa en /docs/getting-started/configuration. Establezca el
Navigation.NavigateTo("/configuration", new NavigationOptions
{
RelativeToCurrentUri = true
});
<NavLink href="configuration" RelativeToCurrentUri="true">Configuration</NavLink>
Blazor Hybrid
En esta sección se describen las nuevas características de Blazor Hybrid.
Las notas de la versión se mostrarán en esta sección a medida que las funciones en vista previa estén disponibles.
SignalR
En esta sección se describen las nuevas características de SignalR.
API mínimas
En esta sección se describen las nuevas características de las API mínimas.
OpenAPI
En esta sección se describen las nuevas características de OpenAPI.
Descripción de las respuestas de archivos binarios
ASP.NET Core 11 presenta compatibilidad con la generación de descripciones de OpenAPI para las operaciones que devuelven respuestas de archivos binarios. Este soporte asigna el FileContentResult tipo de resultado a un esquema de OpenAPI con type: string y format: binary.
Use el método de extensión Produces<T> con T de FileContentResult para especificar el tipo de respuesta y el tipo de contenido.
app.MapPost("/filecontentresult", () =>
{
var content = "This endpoint returns a FileContentResult!"u8.ToArray();
return TypedResults.File(content);
})
.Produces<FileContentResult>(contentType: MediaTypeNames.Application.Octet);
El documento de OpenAPI generado describe la respuesta del punto de conexión como:
responses:
'200':
description: OK
content:
application/octet-stream:
schema:
$ref: '#/components/schemas/FileContentResult'
FileContentResult se define en components/schemas como:
components:
schemas:
FileContentResult:
type: string
format: binary
Autenticación y autorización
En esta sección se describen las nuevas características de autenticación y autorización.
TimeProvider compatibilidad con ASP.NET Core Identity
ASP.NET Core Identity ahora usa TimeProvider en lugar de DateTime y DateTimeOffset para todas las operaciones relacionadas con el tiempo. Este cambio hace Identity que los componentes se puedan probar más y proporcionan un mejor control a lo largo del tiempo en pruebas y escenarios especializados.
En el ejemplo siguiente se muestra cómo usar un objeto simulado TimeProvider para probar Identity funcionalidades:
// In tests
var fakeTimeProvider = new FakeTimeProvider(
new DateTimeOffset(2024, 1, 1, 0, 0, 0, TimeSpan.Zero));
services.AddSingleton<TimeProvider>(fakeTimeProvider);
services.AddIdentity<IdentityUser, IdentityRole>();
// Identity will now use the fake time provider
Mediante TimeProvider, es más fácil escribir pruebas deterministas para funciones críticas para el Identity tiempo, como la expiración del token, las duraciones de bloqueo y la validación del sello de seguridad.
Varios
En esta sección se describen varias características nuevas de .NET 11.
interfaz IOutputCachePolicyProvider
ASP.NET Core en .NET 11 proporciona la [IOutputCachePolicyProvider](https://source.dot.net/#Microsoft.AspNetCore.OutputCaching/[IOutputCachePolicyProvider.cs](https://source.dot.net/#Microsoft.AspNetCore.OutputCaching/IOutputCachePolicyProvider.cs)' interfaz para implementar la lógica de selección de directivas de almacenamiento en caché de salida personalizada. Con esta interfaz, las aplicaciones pueden determinar la directiva de almacenamiento en caché base predeterminada, comprobar la existencia de directivas con nombre y admitir escenarios avanzados en los que las directivas se deben resolver dinámicamente. Algunos ejemplos incluyen cargar directivas de orígenes de configuración externos, bases de datos o aplicar reglas de caché específicas del inquilino.
El código siguiente muestra la IOutputCachePolicyProvider interfaz :
public interface IOutputCachePolicyProvider
{
IReadOnlyList<IOutputCachePolicy> GetBasePolicies();
ValueTask<IOutputCachePolicy?> GetPolicyAsync(string policyName);
}
¡Gracias @lqlive por esta contribución!
Certificados de desarrollo de confianza automática en WSL
La configuración del certificado de desarrollo ahora confía automáticamente en certificados en entornos de WSL (Subsistema de Windows para Linux). Cuando se ejecuta dotnet dev-certs https --trust en WSL, el certificado se instala automáticamente y se confía tanto en el entorno de WSL como en Windows, lo que elimina la configuración de confianza manual.
# Automatically trusts certificates in both WSL and Windows
dotnet dev-certs https --trust
Esta mejora simplifica la experiencia de desarrollo al usar WSL, lo que elimina un punto de fricción común para los desarrolladores que trabajan en entornos Linux en Windows.
¡Gracias @StickFun por esta contribución!
Colaborar con nosotros en GitHub
El origen de este contenido se puede encontrar en GitHub, donde también puede crear y revisar problemas y solicitudes de incorporación de cambios. Para más información, consulte nuestra guía para colaboradores.
