Cambios importantes en .NET Core 3.0

  • Artículo

Si va a migrar a la versión 3.0 de .NET Core, ASP.NET Core o EF Core, es posible que los cambios importantes de este artículo afecten a la aplicación.

ASP.NET Core

Se han quitado las API Antiforgery, CORS, Diagnostics, MVC y Routing obsoletas

Se han quitado los miembros obsoletos y los modificadores de compatibilidad en ASP.NET Core 2.2.

Versión introducida

3.0

Motivo del cambio

Mejora de la superficie de API a lo largo del tiempo.

Aunque el destino es .NET Core 2,2, siga la guía de los mensajes de compilación obsoletos para adoptar nuevas API en su lugar.

Categoría

ASP.NET Core

API afectadas

Los tipos y miembros siguientes se marcaron como obsoletos para ASP.NET Core 2.1 y 2.2:

Tipos

  • Microsoft.AspNetCore.Diagnostics.Views.WelcomePage
  • Microsoft.AspNetCore.DiagnosticsViewPage.Views.AttributeValue
  • Microsoft.AspNetCore.DiagnosticsViewPage.Views.BaseView
  • Microsoft.AspNetCore.DiagnosticsViewPage.Views.HelperResult
  • Microsoft.AspNetCore.Mvc.Formatters.Xml.ProblemDetails21Wrapper
  • Microsoft.AspNetCore.Mvc.Formatters.Xml.ValidationProblemDetails21Wrapper
  • Microsoft.AspNetCore.Mvc.Razor.Compilation.ViewsFeatureProvider
  • Microsoft.AspNetCore.Mvc.RazorPages.Infrastructure.PageArgumentBinder
  • Microsoft.AspNetCore.Routing.IRouteValuesAddressMetadata
  • Microsoft.AspNetCore.Routing.RouteValuesAddressMetadata

Constructores

  • Microsoft.AspNetCore.Cors.Infrastructure.CorsService(IOptions{CorsOptions})
  • Microsoft.AspNetCore.Routing.Tree.TreeRouteBuilder(ILoggerFactory,UrlEncoder,ObjectPool{UriBuildingContext},IInlineConstraintResolver)
  • Microsoft.AspNetCore.Mvc.Formatters.OutputFormatterCanWriteContext
  • Microsoft.AspNetCore.Mvc.ApiExplorer.DefaultApiDescriptionProvider(IOptions{MvcOptions},IInlineConstraintResolver,IModelMetadataProvider)
  • Microsoft.AspNetCore.Mvc.ApiExplorer.DefaultApiDescriptionProvider(IOptions{MvcOptions},IInlineConstraintResolver,IModelMetadataProvider,IActionResultTypeMapper)
  • Microsoft.AspNetCore.Mvc.Formatters.FormatFilter(IOptions{MvcOptions})
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.ArrayModelBinder`1(IModelBinder)
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.ByteArrayModelBinder
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.CollectionModelBinder`1(IModelBinder)
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.ComplexTypeModelBinder(IDictionary`2)
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.DictionaryModelBinder`2(IModelBinder,IModelBinder)
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.DoubleModelBinder(System.Globalization.NumberStyles)
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.FloatModelBinder(System.Globalization.NumberStyles)
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.FormCollectionModelBinder
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.FormFileModelBinder
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.HeaderModelBinder
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.KeyValuePairModelBinder`2(IModelBinder,IModelBinder)
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.SimpleTypeModelBinder(System.Type)
  • Microsoft.AspNetCore.Mvc.ModelBinding.ModelAttributes(IEnumerable{System.Object})
  • Microsoft.AspNetCore.Mvc.ModelBinding.ModelAttributes(IEnumerable{System.Object},IEnumerable{System.Object})
  • Microsoft.AspNetCore.Mvc.ModelBinding.ModelBinderFactory(IModelMetadataProvider,IOptions{MvcOptions})
  • Microsoft.AspNetCore.Mvc.ModelBinding.ParameterBinder(IModelMetadataProvider,IModelBinderFactory,IObjectModelValidator)
  • Microsoft.AspNetCore.Mvc.Routing.KnownRouteValueConstraint()
  • Microsoft.AspNetCore.Mvc.Formatters.XmlDataContractSerializerInputFormatter
  • Microsoft.AspNetCore.Mvc.Formatters.XmlDataContractSerializerInputFormatter(System.Boolean)
  • Microsoft.AspNetCore.Mvc.Formatters.XmlDataContractSerializerInputFormatter(MvcOptions)
  • Microsoft.AspNetCore.Mvc.Formatters.XmlSerializerInputFormatter
  • Microsoft.AspNetCore.Mvc.Formatters.XmlSerializerInputFormatter(System.Boolean)
  • Microsoft.AspNetCore.Mvc.Formatters.XmlSerializerInputFormatter(MvcOptions)
  • Microsoft.AspNetCore.Mvc.TagHelpers.ImageTagHelper(IHostingEnvironment,IMemoryCache,HtmlEncoder,IUrlHelperFactory)
  • Microsoft.AspNetCore.Mvc.TagHelpers.LinkTagHelper(IHostingEnvironment,IMemoryCache,HtmlEncoder,JavaScriptEncoder,IUrlHelperFactory)
  • Microsoft.AspNetCore.Mvc.TagHelpers.ScriptTagHelper(IHostingEnvironment,IMemoryCache,HtmlEncoder,JavaScriptEncoder,IUrlHelperFactory)
  • Microsoft.AspNetCore.Mvc.RazorPages.Infrastructure.RazorPageAdapter(RazorPageBase)

Propiedades

  • Microsoft.AspNetCore.Antiforgery.AntiforgeryOptions.CookieDomain
  • Microsoft.AspNetCore.Antiforgery.AntiforgeryOptions.CookieName
  • Microsoft.AspNetCore.Antiforgery.AntiforgeryOptions.CookiePath
  • Microsoft.AspNetCore.Antiforgery.AntiforgeryOptions.RequireSsl
  • Microsoft.AspNetCore.Mvc.ApiBehaviorOptions.AllowInferringBindingSourceForCollectionTypesAsFromQuery
  • Microsoft.AspNetCore.Mvc.ApiBehaviorOptions.SuppressUseValidationProblemDetailsForInvalidModelStateResponses
  • Microsoft.AspNetCore.Mvc.CookieTempDataProviderOptions.CookieName
  • Microsoft.AspNetCore.Mvc.CookieTempDataProviderOptions.Domain
  • Microsoft.AspNetCore.Mvc.CookieTempDataProviderOptions.Path
  • Microsoft.AspNetCore.Mvc.DataAnnotations.MvcDataAnnotationsLocalizationOptions.AllowDataAnnotationsLocalizationForEnumDisplayAttributes
  • Microsoft.AspNetCore.Mvc.Formatters.Xml.MvcXmlOptions.AllowRfc7807CompliantProblemDetailsFormat
  • Microsoft.AspNetCore.Mvc.MvcOptions.AllowBindingHeaderValuesToNonStringModelTypes
  • Microsoft.AspNetCore.Mvc.MvcOptions.AllowCombiningAuthorizeFilters
  • Microsoft.AspNetCore.Mvc.MvcOptions.AllowShortCircuitingValidationWhenNoValidatorsArePresent
  • Microsoft.AspNetCore.Mvc.MvcOptions.AllowValidatingTopLevelNodes
  • Microsoft.AspNetCore.Mvc.MvcOptions.InputFormatterExceptionPolicy
  • Microsoft.AspNetCore.Mvc.MvcOptions.SuppressBindingUndefinedValueToEnumType
  • Microsoft.AspNetCore.Mvc.MvcViewOptions.AllowRenderingMaxLengthAttribute
  • Microsoft.AspNetCore.Mvc.MvcViewOptions.SuppressTempDataAttributePrefix
  • Microsoft.AspNetCore.Mvc.RazorPages.RazorPagesOptions.AllowAreas
  • Microsoft.AspNetCore.Mvc.RazorPages.RazorPagesOptions.AllowDefaultHandlingForOptionsRequests
  • Microsoft.AspNetCore.Mvc.RazorPages.RazorPagesOptions.AllowMappingHeadRequestsToGetHandler

Métodos

API "Pubternal" quitadas

Para mantener mejor la superficie de la API pública de ASP.NET Core, la mayoría de los tipos de los espacios de nombres *.Internal (conocidos como API "pubternal") se han vuelto realmente internos. Los miembros de estos espacios de nombres nunca debían admitirse como API de acceso público. Las API podían dividirse en versiones secundarias y con frecuencia lo hacían. El código que depende de estas API se divide cuando se actualiza a ASP.NET Core 3.0.

Para más información, consulte dotnet/aspnetcore#4932 y dotnet/aspnetcore#11312.

Versión introducida

3.0

Comportamiento anterior

Las API afectadas se marcan con el modificador de acceso public y existen en los espacios de nombres *.Internal.

Comportamiento nuevo

Las API afectadas se marcan con el modificador de acceso internal y ya no se pueden usar en el código fuera de ese ensamblado.

Motivo del cambio

Las instrucciones para estas API de "pubternal" eran las siguientes:

  • Podían cambiar sin previo aviso.
  • No estaban sujetas a las directivas de .NET para evitar cambios importantes.

La salida de las API public (incluso en los espacios de nombres de *.Internal) era confusa para los clientes.

Deje de usar estas API "pubternal". Si tiene alguna pregunta sobre API alternativas, abra una incidencia en el repositorio dotnet/aspnetcore.

Por ejemplo, considere el siguiente código de almacenamiento en búfer de solicitudes HTTP en un proyecto ASP.NET Core 2.2. El método de extensión EnableRewind existe en el espacio de nombres Microsoft.AspNetCore.Http.Internal.

HttpContext.Request.EnableRewind();

En un proyecto ASP.NET Core 3.0, reemplace la llamada EnableRewind por una llamada al método de extensión EnableBuffering. La característica de almacenamiento en búfer de solicitudes funciona igual que lo hacía antes. EnableBuffering llama a la API internal ahora.

HttpContext.Request.EnableBuffering();

Categoría

ASP.NET Core

API afectadas

Todas las API de los espacios de nombres Microsoft.AspNetCore.* y Microsoft.Extensions.* que tienen un segmento Internal en el nombre del espacio de nombres. Por ejemplo:

  • Microsoft.AspNetCore.Authentication.Internal
  • Microsoft.AspNetCore.Builder.Internal
  • Microsoft.AspNetCore.DataProtection.Cng.Internal
  • Microsoft.AspNetCore.DataProtection.Internal
  • Microsoft.AspNetCore.Hosting.Internal
  • Microsoft.AspNetCore.Http.Internal
  • Microsoft.AspNetCore.Mvc.Core.Infrastructure
  • Microsoft.AspNetCore.Mvc.Core.Internal
  • Microsoft.AspNetCore.Mvc.Cors.Internal
  • Microsoft.AspNetCore.Mvc.DataAnnotations.Internal
  • Microsoft.AspNetCore.Mvc.Formatters.Internal
  • Microsoft.AspNetCore.Mvc.Formatters.Json.Internal
  • Microsoft.AspNetCore.Mvc.Formatters.Xml.Internal
  • Microsoft.AspNetCore.Mvc.Internal
  • Microsoft.AspNetCore.Mvc.ModelBinding.Internal
  • Microsoft.AspNetCore.Mvc.Razor.Internal
  • Microsoft.AspNetCore.Mvc.RazorPages.Internal
  • Microsoft.AspNetCore.Mvc.TagHelpers.Internal
  • Microsoft.AspNetCore.Mvc.ViewFeatures.Internal
  • Microsoft.AspNetCore.Rewrite.Internal
  • Microsoft.AspNetCore.Routing.Internal
  • Microsoft.AspNetCore.Server.Kestrel.Core.Adapter.Internal
  • Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http
  • Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Infrastructure
  • Microsoft.AspNetCore.Server.Kestrel.Https.Internal

Autenticación: Google+ se ha dejado en desuso y se ha reemplazado

Google está empezando a apagar el inicio de sesión de Google+ en las aplicaciones a partir del 28 de enero de 2019.

Descripción del cambio

ASP.NET 4.x y ASP.NET Core han estado usando las API de inicio de sesión de Google+ para autenticar a los usuarios de cuentas de Google en las aplicaciones web. Los paquetes NuGet afectados son Microsoft.AspNetCore.Authentication.Google para ASP.NET Core y Microsoft.Owin.Security.Google para Microsoft.Owin con ASP.NET Web Forms y MVC.

Las API de reemplazo de Google utilizan un formato y un origen de datos distintos. Las mitigaciones y soluciones que se proporcionan a continuación tienen en cuenta los cambios estructurales. Las aplicaciones deben comprobar que los datos en sí cumplen sus requisitos. Por ejemplo, los nombres, las direcciones de correo electrónico, los vínculos de perfil y las fotos de perfil pueden proporcionar valores ligeramente distintos a los anteriores.

Versión introducida

Todas las versiones. Este cambio es externo a ASP.NET Core.

Owin con ASP.NET Web Forms y MVC

En el caso de Microsoft.Owin 3.1.0 y versiones posteriores, se describe una mitigación temporal aquí. Las aplicaciones deben completar las pruebas con la mitigación para comprobar si hay cambios en el formato de datos. Existen planes para lanzar Microsoft.Owin 4.0.1 con una corrección. Las aplicaciones que usen cualquier versión anterior deben actualizarse a la versión 4.0.1.

ASP.NET Core 1.x

La mitigación en Owin con ASP.NET Web Forms y MVC puede adaptarse a ASP.NET Core 1.x. Las revisiones del paquete NuGet no están planeadas porque 1.x ha alcanzado el estado final del ciclo de vida.

ASP.NET Core 2.x

En el caso la versión 2.x de Microsoft.AspNetCore.Authentication.Google, reemplace la llamada existente a AddGoogle en Startup.ConfigureServices por el código siguiente:

.AddGoogle(o =>
{
    o.ClientId = Configuration["Authentication:Google:ClientId"];
    o.ClientSecret = Configuration["Authentication:Google:ClientSecret"];
    o.UserInformationEndpoint = "https://www.googleapis.com/oauth2/v2/userinfo";
    o.ClaimActions.Clear();
    o.ClaimActions.MapJsonKey(ClaimTypes.NameIdentifier, "id");
    o.ClaimActions.MapJsonKey(ClaimTypes.Name, "name");
    o.ClaimActions.MapJsonKey(ClaimTypes.GivenName, "given_name");
    o.ClaimActions.MapJsonKey(ClaimTypes.Surname, "family_name");
    o.ClaimActions.MapJsonKey("urn:google:profile", "link");
    o.ClaimActions.MapJsonKey(ClaimTypes.Email, "email");
});

Las revisiones 2.1 y 2.2 de febrero incorporaron la reconfiguración anterior como el nuevo valor predeterminado. No hay ninguna revisión planeada para ASP.NET Core 2.0 porque ha alcanzado el final del ciclo de vida.

ASP.NET Core 3.0

La mitigación proporcionada para ASP.NET Core 2.x también puede usarse para ASP.NET Core 3.0. En versiones preliminares futuras de la versión 3.0, se puede quitar el paquete Microsoft.AspNetCore.Authentication.Google. A los usuarios se les dirigirá a Microsoft.AspNetCore.Authentication.OpenIdConnect en su lugar. El código siguiente muestra cómo reemplazar AddGoogle por AddOpenIdConnect en Startup.ConfigureServices. Este reemplazo se puede usar con ASP.NET Core 2.0 y versiones posteriores, y se puede adaptar para ASP.NET Core 1.x, según sea necesario.

.AddOpenIdConnect("Google", o =>
{
    o.ClientId = Configuration["Authentication:Google:ClientId"];
    o.ClientSecret = Configuration["Authentication:Google:ClientSecret"];
    o.Authority = "https://accounts.google.com";
    o.ResponseType = OpenIdConnectResponseType.Code;
    o.CallbackPath = "/signin-google"; // Or register the default "/signin-oidc"
    o.Scope.Add("email");
});
JwtSecurityTokenHandler.DefaultInboundClaimTypeMap.Clear();

Categoría

ASP.NET Core

API afectadas

Microsoft.AspNetCore.Authentication.Google

Autenticación: se ha quitado la propiedad HttpContext.Authentication

La propiedad Authentication en desuso se ha quitado en HttpContext.

Descripción del cambio

Como parte de dotnet/aspnetcore#6504, la propiedad Authentication en desuso se ha quitado en HttpContext. La propiedad Authentication se ha dejado en desuso desde la versión 2.0. Se ha publicado una guía de migración para migrar código con esta propiedad en desuso a las nuevas API de reemplazo. Las clases o API restantes no utilizadas relacionadas con la pila de autenticación antigua ASP.NET Core 1.x se han quitado en la confirmación dotnet/aspnetcore@d7a7c65.

Para obtener información, vea dotnet/aspnetcore#6533.

Versión introducida

3.0

Motivo del cambio

Las API de ASP.NET Core 1.0 se han reemplazado por métodos de extensión en Microsoft.AspNetCore.Authentication.AuthenticationHttpContextExtensions.

Consulte la guía de migración.

Categoría

ASP.NET Core

API afectadas

Autenticación: se han reemplazado los tipos Newtonsoft.Json

En ASP.NET Core 3.0, los tipos de Newtonsoft.Json utilizados en las API de autenticación se han reemplazado por tipos de System.Text.Json. Excepto en los casos siguientes, el uso básico de los paquetes de autenticación no se ve afectado:

  • Clases que se derivan de los proveedores de OAuth, como las de aspnet-contrib.
  • Implementaciones avanzadas de manipulación de notificaciones.

Para obtener más información, consulte dotnet/aspnetcore#7105. Para obtener información, vea dotnet/aspnetcore#7289.

Versión introducida

3.0

En el caso de las implementaciones de OAuth derivadas, el cambio más común es reemplazar JObject.Parse por JsonDocument.Parse en la invalidación CreateTicketAsync, tal como se muestra aquí. JsonDocument implementa IDisposable.

En la lista siguiente se describen los cambios conocidos:

Categoría

ASP.NET Core

API afectadas

Autenticación: se ha cambiado la firma ExchangeCodeAsync de OAuthHandler

En ASP.NET Core 3.0, la firma de OAuthHandler.ExchangeCodeAsync cambió de:

protected virtual System.Threading.Tasks.Task<Microsoft.AspNetCore.Authentication.OAuth.OAuthTokenResponse> ExchangeCodeAsync(string code, string redirectUri) { throw null; }

A:

protected virtual System.Threading.Tasks.Task<Microsoft.AspNetCore.Authentication.OAuth.OAuthTokenResponse> ExchangeCodeAsync(Microsoft.AspNetCore.Authentication.OAuth.OAuthCodeExchangeContext context) { throw null; }

Versión introducida

3.0

Comportamiento anterior

Las cadenas code y redirectUri se pasaron como argumentos independientes.

Comportamiento nuevo

Code y RedirectUri son propiedades de OAuthCodeExchangeContext que se pueden establecer mediante el constructor de OAuthCodeExchangeContext. El nuevo tipo de OAuthCodeExchangeContext es el único argumento que se pasa a OAuthHandler.ExchangeCodeAsync.

Motivo del cambio

Este cambio permite proporcionar parámetros adicionales de forma no interrumpida. No es necesario crear sobrecargas nuevas de ExchangeCodeAsync.

Construya un elemento OAuthCodeExchangeContext con los valores adecuados de code y redirectUri. Se debe proporcionar una instancia de AuthenticationProperties. Esta instancia de OAuthCodeExchangeContext única se puede pasar a OAuthHandler.ExchangeCodeAsync en lugar de varios argumentos.

Categoría

ASP.NET Core

API afectadas

OAuthHandler<TOptions>.ExchangeCodeAsync(String, String)

Autorización: la sobrecarga de AddAuthorization se ha movido a otro ensamblado

Se ha cambiado a AddAuthorizationCore el nombre de los métodos AddAuthorization principales que antes se encontraban en Microsoft.AspNetCore.Authorization. Los métodos AddAuthorization antiguos todavía existen, pero ahora se encuentran en el ensamblado Microsoft.AspNetCore.Authorization.Policy. Las aplicaciones en las que se usen ambos métodos no se verán afectadas. Tenga en cuenta que Microsoft.AspNetCore.Authorization.Policy ahora se incluye en el marco compartido en lugar de en un paquete independiente, tal como se describe en Marco compartido: se han quitado los ensamblados de Microsoft.AspNetCore.

Versión introducida

3.0

Comportamiento anterior

Los métodos AddAuthorization existían en Microsoft.AspNetCore.Authorization.

Comportamiento nuevo

Los métodos AddAuthorization existen en Microsoft.AspNetCore.Authorization.Policy. AddAuthorizationCore es el nuevo nombre de los métodos antiguos.

Motivo del cambio

AddAuthorization es un nombre de método más indicado para agregar todos los servicios comunes necesarios para la autorización.

Agregue una referencia a Microsoft.AspNetCore.Authorization.Policy o, en su lugar, use AddAuthorizationCore.

Categoría

ASP.NET Core

API afectadas

Microsoft.Extensions.DependencyInjection.AuthorizationServiceCollectionExtensions.AddAuthorization(IServiceCollection, Action<AuthorizationOptions>)

Autorización: se ha quitado IAllowAnonymous de AuthorizationFilterContext.Filters

A partir de ASP.NET Core 3.0, MVC no agrega AllowAnonymousFilters para los atributos [AllowAnonymous] que se detectaron en los controladores y métodos de acción. Este cambio se dirige localmente para los derivados de AuthorizeAttribute, pero es un cambio importante en las implementaciones de IAsyncAuthorizationFilter y IAuthorizationFilter. Estas implementaciones contenidas en un atributo [TypeFilter] son una conocidas y compatibles para lograr la autorización basada en atributos fuertemente tipados cuando se requieren tanto la configuración como la inserción de dependencias.

Versión introducida

3.0

Comportamiento anterior

IAllowAnonymous aparecía en la colección AuthorizationFilterContext.Filters. La prueba de la presencia de la interfaz era un enfoque válido para invalidar o deshabilitar el filtro en métodos de controlador individuales.

Comportamiento nuevo

IAllowAnonymous ya no aparece en la colección AuthorizationFilterContext.Filters. Las implementaciones IAsyncAuthorizationFilter que dependen del comportamiento anterior normalmente producen respuestas intermitentes HTTP 401 no autorizadas o HTTP 403 prohibidas.

Motivo del cambio

Se presentó una nueva estrategia de enrutamiento de puntos de conexión en ASP.NET Core 3.0.

Busque IAllowAnonymous en los metadatos del punto de conexión. Por ejemplo:

var endpoint = context.HttpContext.GetEndpoint();
if (endpoint?.Metadata?.GetMetadata<IAllowAnonymous>() != null)
{
}

Un ejemplo de esta técnica se encuentra en este método HasAllowAnonymous.

Categoría

ASP.NET Core

API afectadas

None

Autorización: las implementaciones de IAuthorizationPolicyProvider requieren un método nuevo

En ASP.NET Core 3.0, se ha agregado un nuevo método GetFallbackPolicyAsync a IAuthorizationPolicyProvider. El middleware de autorización usa esta directiva de reserva cuando no se especifica ninguna directiva.

Para obtener más información, consulte dotnet/aspnetcore#9759.

Versión introducida

3.0

Comportamiento anterior

Las implementaciones de IAuthorizationPolicyProvider no requerían un método GetFallbackPolicyAsync.

Comportamiento nuevo

Las implementaciones de IAuthorizationPolicyProvider requieren un método GetFallbackPolicyAsync.

Motivo del cambio

Se necesitaba un nuevo método para que el nuevo AuthorizationMiddleware lo usara cuando no se especificara ninguna directiva.

Agregue el método GetFallbackPolicyAsync a las implementaciones de IAuthorizationPolicyProvider.

Categoría

ASP.NET Core

API afectadas

Microsoft.AspNetCore.Authorization.IAuthorizationPolicyProvider

Almacenamiento en caché: se ha quitado la propiedad CompactOnMemoryPressure

En la versión ASP.NET Core 3.0 se han quitado las API MemoryCacheOptions obsoletas.

Descripción del cambio

Este cambio es una continuación de aspnet/Caching#221. Para obtener información, vea dotnet/extensions#1062.

Versión introducida

3.0

Comportamiento anterior

La propiedad MemoryCacheOptions.CompactOnMemoryPressure estaba disponible.

Comportamiento nuevo

Se ha quitado la propiedad MemoryCacheOptions.CompactOnMemoryPressure.

Motivo del cambio

La compactación automática de la caché provocaba problemas. Para evitar un comportamiento inesperado, solo se debe compactar la caché cuando sea necesario.

Para compactar la caché, realice la conversión a un tipo heredado MemoryCache y llame a Compact cuando sea necesario.

Categoría

ASP.NET Core

API afectadas

MemoryCacheOptions.CompactOnMemoryPressure

Almacenamiento en caché: Microsoft.Extensions.Caching.SqlServer usa el paquete nuevo SqlClient

El paquete Microsoft.Extensions.Caching.SqlServer usará el paquete nuevo Microsoft.Data.SqlClient en lugar del System.Data.SqlClient. Este cambio podría producir pequeños cambios en el comportamiento. Para obtener más información, vea Introducción al nuevo Microsoft.Data.SqlClient.

Versión introducida

3.0

Comportamiento anterior

El paquete Microsoft.Extensions.Caching.SqlServer usaba el paquete System.Data.SqlClient.

Comportamiento nuevo

Microsoft.Extensions.Caching.SqlServer ahora usa el paquete Microsoft.Data.SqlClient.

Motivo del cambio

Microsoft.Data.SqlClient es un nuevo paquete que se ha creado a partir de System.Data.SqlClient. A partir de ahora, aquí es donde se realizará todo el trabajo de las nuevas características.

Los clientes no deben preocuparse por este cambio importante, a menos que usaran los tipos que devolvía el paquete Microsoft.Extensions.Caching.SqlServer y los convirtieran en tipos de System.Data.SqlClient. Por ejemplo, si algún usuario estuviera convirtiendo un elemento DbConnection al tipo de SqlConnection anterior, tendría que cambiar la conversión al nuevo tipo de Microsoft.Data.SqlClient.SqlConnection.

Categoría

ASP.NET Core

API afectadas

None

Almacenamiento en caché: los tipos "pubternal" de ResponseCaching se han cambiado a internal

En ASP.NET Core 3.0, los tipos "pubternal" de ResponseCaching han cambiado a internal.

Además, las implementaciones predeterminadas de IResponseCachingPolicyProvider y IResponseCachingKeyProvider ya no se agregan a los servicios como parte del método AddResponseCaching.

Descripción del cambio

In ASP.NET Core, los tipos "pubternal" se declaran como public pero residen en un espacio de nombres con un sufijo .Internal. Aunque estos tipos son públicos, no tienen ninguna directiva compatible y están sujetos a cambios importantes. Desafortunadamente, el uso accidental de estos tipos es habitual, lo que da lugar a cambios importantes en estos proyectos y limita la capacidad de mantener el marco.

Versión introducida

3.0

Comportamiento anterior

Estos tipos eran visibles públicamente, pero no eran compatibles.

Comportamiento nuevo

Estos tipos ahora son internal.

Motivo del cambio

El ámbito de internal refleja mejor la directiva no compatible.

Copiar los tipos que usa la aplicación o biblioteca.

Categoría

ASP.NET Core

API afectadas

Protección de datos: uso de nuevas API de Azure Storage por parte de DataProtection.Blobs

Azure.Extensions.AspNetCore.DataProtection.Blobs depende de las bibliotecas de Azure Storage. Estas bibliotecas han cambiado el nombre de los ensamblados, paquetes y espacios de nombres. A partir de ASP.NET Core 3.0, Azure.Extensions.AspNetCore.DataProtection.Blobs utiliza las nuevas API y paquetes con prefijo Azure.Storage..

Si tiene preguntas sobre las API de Azure Storage, utilice https://github.com/Azure/azure-storage-net. Para obtener información sobre esta incidencia, consulte dotnet/aspnetcore#19570.

Versión introducida

3.0

Comportamiento anterior

El paquete hacía referencia al paquete NuGet WindowsAzure.Storage. El paquete hace referencia al paquete NuGet Microsoft.Azure.Storage.Blob.

Comportamiento nuevo

El paquete hace referencia al paquete NuGet Azure.Storage.Blob.

Motivo del cambio

Este cambio permite a Azure.Extensions.AspNetCore.DataProtection.Blobs migrar a los paquetes de Azure Storage recomendados.

Si todavía necesita usar las API de Azure Storage anteriores con ASP.NET Core 3.0, agregue una dependencia directa al paquete WindowsAzure.Storage o Microsoft.Azure.Storage. Este paquete se puede instalar junto con las nuevas API de Azure.Storage.

En muchos casos, la actualización solo implica cambiar las instrucciones using para usar los espacios de nombres nuevos:

- using Microsoft.WindowsAzure.Storage;
- using Microsoft.WindowsAzure.Storage.Blob;
- using Microsoft.Azure.Storage;
- using Microsoft.Azure.Storage.Blob;
+ using Azure.Storage;
+ using Azure.Storage.Blobs;

Categoría

ASP.NET Core

API afectadas

None

Hospedaje: se ha quitado AspNetCoreModule V1 del conjunto de hospedaje de Windows

A partir de ASP.NET Core 3.0, el conjunto de hospedaje de Windows no incluirá AspNetCoreModule (ANCM) V1.

ANCM V2 es compatible con las versiones anteriores de ANCM OutOfProcess y se recomienda para su uso con aplicaciones de ASP.NET Core 3.0.

Para obtener información, vea dotnet/aspnetcore#7095.

Versión introducida

3.0

Comportamiento anterior

ANCM V1 está incluido en el conjunto de hospedaje de Windows.

Comportamiento nuevo

ANCM V1 no está incluido en el conjunto de hospedaje de Windows.

Motivo del cambio

ANCM V2 es compatible con las versiones anteriores de ANCM OutOfProcess y se recomienda para su uso con aplicaciones de ASP.NET Core 3.0.

Use ANCM V2 con aplicaciones de ASP.NET Core 3.0.

Si se requiere ANCM V1, se puede instalar mediante el conjunto de hospedaje de Windows ASP.NET Core 2.1 o 2.2.

Este cambio interrumpirá las aplicaciones de ASP.NET Core 3.0 que:

  • Participen del uso de ANCM V1 con <AspNetCoreModuleName>AspNetCoreModule</AspNetCoreModuleName>.
  • Tengan un archivo web.config personalizado con <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />.

Categoría

ASP.NET Core

API afectadas

None

Hospedaje: el host genérico restringe la inserción del constructor de Startup

Los únicos tipos que admite el host genérico para la inserción del constructor de la clase Startup son IHostEnvironment, IWebHostEnvironment e IConfiguration. Las aplicaciones que usan WebHost no se ven afectadas.

Descripción del cambio

Antes de ASP.NET Core 3.0, se podía usar la inserción de constructores para tipos arbitrarios en el constructor de la clase Startup. En ASP.NET Core 3.0, se ha cambiado la plataforma de la pila web a la biblioteca de host genéricos. Puede ver el cambio en el archivo Program.cs de las plantillas:

ASP.NET Core 2.x:

https://github.com/dotnet/aspnetcore/blob/5cb615fcbe8559e49042e93394008077e30454c0/src/Templating/src/Microsoft.DotNet.Web.ProjectTemplates/content/EmptyWeb-CSharp/Program.cs#L20-L22

ASP.NET Core 3.0:

https://github.com/dotnet/aspnetcore/blob/b1ca2c1155da3920f0df5108b9fedbe82efaa11c/src/ProjectTemplates/Web.ProjectTemplates/content/EmptyWeb-CSharp/Program.cs#L19-L24

Host usa un contenedor de inserción de dependencias (DI) para compilar la aplicación. WebHost usa dos contenedores: uno para el host y otro para la aplicación. Como resultado, el constructor de Startup ya no admite la inserción de servicios personalizados. Solo se pueden insertar IHostEnvironment, IWebHostEnvironment e IConfiguration. Este cambio evita problemas de DI, como la creación duplicada de un servicio singleton.

Versión introducida

3.0

Motivo del cambio

Este cambio es consecuencia del cambio de plataforma de la pila web a la biblioteca de host genéricos.

Inserte los servicios en la firma del método Startup.Configure. Por ejemplo:

public void Configure(IApplicationBuilder app, IOptions<MyOptions> options)

Categoría

ASP.NET Core

API afectadas

None

Hospedaje: redireccionamiento de HTTPS habilitado para aplicaciones fuera de proceso de IIS

La versión 13.0.19218.0 del módulo ASP.NET Core (ANCM) para el hospedaje a través de IIS fuera de proceso habilita una característica de redireccionamiento de HTTPS existente para aplicaciones ASP.NET Core 3.0 y 2.2.

Para obtener información, vea dotnet/AspNetCore#15243.

Versión introducida

3.0

Comportamiento anterior

La plantilla de proyecto de ASP.NET Core 2.1 incorporó por primera vez compatibilidad con métodos de middleware de HTTPS como UseHttpsRedirection y UseHsts. La habilitación del redireccionamiento de HTTPS exigía la adición de configuración, ya que las aplicaciones en desarrollo no usan el puerto predeterminado 443. La seguridad de transporte estricta de HTTP (HSTS) solo está activa si la solicitud ya usa HTTPS. Localhost se omite de forma predeterminada.

Comportamiento nuevo

En ASP.NET Core 3.0, el escenario de HTTPS de IIS se ha mejorado. Con la mejora, una aplicación puede detectar los puertos HTTPS del servidor y hacer que UseHttpsRedirection funcione de forma predeterminada. El componente en proceso ha logrado la detección de puertos con la característica IServerAddresses, que solo afecta a las aplicaciones ASP.NET Core 3.0, dado que a la biblioteca en proceso se le asigna la versión del marco de trabajo. El componente fuera de proceso ha cambiado para agregar automáticamente la variable de entorno ASPNETCORE_HTTPS_PORT. Este cambio afecta a las aplicaciones ASP.NET Core 2.2 y 3.0, ya que el componente fuera de proceso se comparte de forma global. Las aplicaciones ASP.NET Core 2.1 no se ven afectadas porque usan una versión anterior de ANCM de forma predeterminada.

El comportamiento anterior se modificó en ASP.NET Core 3.0.1 y 3.1.0 (versión preliminar 3) a fin de invertir los cambios de comportamiento en ASP.NET Core 2.x. Estos cambios solo afectan a aplicaciones fuera de proceso de IIS.

Como se ha explicado anteriormente, la instalación de ASP.NET Core 3.0.0 tenía el efecto secundario de activar también el middleware de UseHttpsRedirection en las aplicaciones ASP.NET Core 2.x. Se ha realizado un cambio en ANCM en ASP.NET Core 3.0.1 y 3.1.0 (versión preliminar 3) que consiste en que su instalación ya no tiene este efecto en las aplicaciones ASP.NET Core 2.x. La variable de entorno ASPNETCORE_HTTPS_PORT que ANCM rellenaba en ASP.NET Core 3.0.0 se ha cambiado a ASPNETCORE_ANCM_HTTPS_PORT en ASP.NET Core 3.0.1 y 3.1.0 (versión preliminar 3). UseHttpsRedirection también se ha actualizado en estas versiones para comprender las variables antiguas y nuevas. ASP.NET Core 2.x no se va a actualizar. Por eso, revierte al comportamiento anterior de estar deshabilitado de forma predeterminada.

Motivo del cambio

Funcionalidad mejorada de ASP.NET Core 3.0.

No es necesario hacer nada si se quiere que todos los clientes usen HTTPS. Para permitir que algunos clientes empleen HTTP, siga uno de los pasos siguientes:

  • Quite las llamadas a UseHttpsRedirection y UseHsts del método Startup.Configure del proyecto y vuelva a implementar la aplicación.

  • En el archivo web.config, establezca la variable de entorno ASPNETCORE_HTTPS_PORT en una cadena vacía. Este cambio puede producirse directamente en el servidor sin volver a implementar la aplicación. Por ejemplo:

    <aspNetCore processPath="dotnet" arguments=".\WebApplication3.dll" stdoutLogEnabled="false" stdoutLogFile="\\?\%home%\LogFiles\stdout" >
    <environmentVariables>
    <environmentVariable name="ASPNETCORE_HTTPS_PORT" value="" />
    </environmentVariables>
</aspNetCore>

UseHttpsRedirection todavía se puede:

  • Activar de forma manual en ASP.NET Core 2.x al establecer la variable de entorno ASPNETCORE_HTTPS_PORT en el número de puerto correcto (443 en la mayoría de los escenarios de producción).
  • Desactivar en ASP.NET Core 3.x al definir ASPNETCORE_ANCM_HTTPS_PORT con un valor de cadena vacía. Este valor se establece de la misma manera que en el ejemplo de ASPNETCORE_HTTPS_PORT anterior.

Los equipos que ejecutan aplicaciones ASP.NET Core 3.0.0 deben instalar el runtime de ASP.NET Core 3.0.1 antes de instalar el ANCM de ASP.NET Core 3.1.0 (versión preliminar 3). De este modo se garantiza que UseHttpsRedirection siga funcionando según lo previsto para las aplicaciones ASP.NET Core 3.0.

En Azure App Service, ANCM se implementa conforme a una programación independiente del runtime debido a su naturaleza global. ANCM se implementó en Azure con estos cambios tras la implementación de ASP.NET Core 3.0.1 y 3.1.0.

Categoría

ASP.NET Core

API afectadas

HttpsPolicyBuilderExtensions.UseHttpsRedirection(IApplicationBuilder)

Hospedaje: los tipos IHostingEnvironment e IApplicationLifetime se han marcado como obsoletos y se han reemplazado

Se han introducido tipos nuevos para reemplazar los tipos de IHostingEnvironment y IApplicationLifetime existentes.

Versión introducida

3.0

Comportamiento anterior

Había dos tipos de IHostingEnvironment y IApplicationLifetime distintos de Microsoft.Extensions.Hosting y Microsoft.AspNetCore.Hosting.

Comportamiento nuevo

Los tipos antiguos se han marcado como obsoletos y se han reemplazado por tipos nuevos.

Motivo del cambio

Cuando Microsoft.Extensions.Hosting se presentó en ASP.NET Core 2.1, algunos tipos como IHostingEnvironment y IApplicationLifetime se copiaron de Microsoft.AspNetCore.Hosting. Algunos cambios de ASP.NET Core 3.0 provocan que las aplicaciones incluyan los espacios de nombres Microsoft.Extensions.Hosting y Microsoft.AspNetCore.Hosting. Cualquier uso de estos tipos duplicados produce un error del compilador de "referencia ambigua" cuando se hace referencia a ambos espacios de nombres.

Reemplazados los usos de los tipos anteriores por los tipos recién introducidos, como se indica a continuación:

Tipos obsoletos (advertencia):

Tipos nuevos:

Los métodos de extensión IsDevelopment y IsProduction de IHostEnvironment se encuentran en el espacio de nombres Microsoft.Extensions.Hosting. Es posible que sea necesario agregar ese espacio de nombres al proyecto.

Categoría

ASP.NET Core

API afectadas

Hospedaje: se ha quitado ObjectPoolProvider de las dependencias de WebHostBuilder

Para aumentar la naturaleza de pago por uso de ASP.NET Core, se ha quitado ObjectPoolProvider del conjunto principal de dependencias. Ahora componentes específicos que dependen de ObjectPoolProvider lo agregan por sí mismos.

Para obtener información, vea dotnet/aspnetcore#5944.

Versión introducida

3.0

Comportamiento anterior

WebHostBuilder proporciona ObjectPoolProvider de forma predeterminada en el contenedor de DI.

Comportamiento nuevo

WebHostBuilder ya no proporciona ObjectPoolProvider de forma predeterminada en el contenedor de DI.

Motivo del cambio

Este cambio se ha realizado para aumentar la naturaleza de pago por uso de ASP.NET Core.

Si el componente requiere ObjectPoolProvider, tendrá que agregarlo a las dependencias mediante IServiceCollection.

Categoría

ASP.NET Core

API afectadas

None

HTTP: se ha quitado la extensibilidad de DefaultHttpContext

Como parte de las mejoras de rendimiento de ASP.NET Core 3.0, se ha quitado la extensibilidad de DefaultHttpContext. La clase ahora es sealed. Para obtener más información, consulte dotnet/aspnetcore#6504.

Si en las pruebas unitarias se usa Mock<DefaultHttpContext>, use Mock<HttpContext> o new DefaultHttpContext() en su lugar.

Para obtener información, vea dotnet/aspnetcore#6534.

Versión introducida

3.0

Comportamiento anterior

Las clases se pueden derivar de DefaultHttpContext.

Comportamiento nuevo

Las clases se pueden derivar de DefaultHttpContext.

Motivo del cambio

La extensibilidad se proporcionó inicialmente para permitir la agrupación de HttpContext, pero incorporaba una complejidad innecesaria e impedía otras optimizaciones.

Si usa Mock<DefaultHttpContext> en las pruebas unitarias, empiece a usar Mock<HttpContext> en su lugar.

Categoría

ASP.NET Core

API afectadas

Microsoft.AspNetCore.Http.DefaultHttpContext

HTTP: las constantes HeaderNames se han cambiado a static readonly

A partir de ASP.NET Core 3.0 Preview 5, los campos de Microsoft.Net.Http.Headers.HeaderNames se han cambiado de const a static readonly.

Para obtener información, vea dotnet/aspnetcore#9514.

Versión introducida

3.0

Comportamiento anterior

Estos campos solían ser const.

Comportamiento nuevo

Ahora estos campos son static readonly.

Motivo del cambio

El cambio:

  • Impide que los valores se inserten en los límites de los ensamblados, lo que permite corregirlos según sea necesario.
  • Permite comprobaciones de igualdad de referencia más rápidas.

Vuelva a compilar para la versión 3.0. El código fuente que use estos campos de las maneras siguientes ya no podrá hacerlo:

  • Como un argumento de atributo
  • Como un objeto case en una instrucción switch
  • Al definir otra instancia de const

Para solucionar el cambio importante, use constantes de nombre de encabezado autodefinidas o literales de cadena.

Categoría

ASP.NET Core

API afectadas

Microsoft.Net.Http.Headers.HeaderNames

HTTP: cambios en la infraestructura del cuerpo de respuesta

La infraestructura que respalda un cuerpo de respuesta HTTP ha cambiado. Si usa HttpResponse directamente, no debe realizar ningún cambio en el código. Siga leyendo si ajusta o reemplaza HttpResponse.Body, o si accede a HttpContext.Features.

Versión introducida

3.0

Comportamiento anterior

Había tres API asociadas al cuerpo de respuesta HTTP:

  • IHttpResponseFeature.Body
  • IHttpSendFileFeature.SendFileAsync
  • IHttpBufferingFeature.DisableResponseBuffering

Comportamiento nuevo

Si reemplaza HttpResponse.Body, reemplaza todo el elemento IHttpResponseBodyFeature por un contenedor en torno a la secuencia dada mediante StreamResponseBodyFeature con el fin de proporcionar implementaciones predeterminadas para todas las API esperadas. Al volver a establecer la secuencia original, este cambio se revierte.

Motivo del cambio

La motivación es combinar las API del cuerpo de la respuesta en una única interfaz de características nueva.

Use IHttpResponseBodyFeature donde anteriormente usaba IHttpResponseFeature.Body, IHttpSendFileFeature o IHttpBufferingFeature.

Categoría

ASP.NET Core

API afectadas

SameSite es una opción para cookies que puede ayudar a mitigar algunos ataques de falsificación de solicitud entre sitios (CSRF). Cuando esta opción se presentó inicialmente, se usaron valores predeterminados incoherentes en varias API de ASP.NET Core. La incoherencia ha generado unos resultados confusos. A partir de ASP.NET Core 3.0, estos valores predeterminados están organizados de mejor forma. Debe aceptar participar en esta característica individualmente para cada componente.

Versión introducida

3.0

Comportamiento anterior

Las API de ASP.NET Core similares usaban diferentes valores predeterminados de SameSiteMode. Un ejemplo de la incoherencia se percibe en HttpResponse.Cookies.Append(String, String) y HttpResponse.Cookies.Append(String, String, CookieOptions), que tenían como valor predeterminado SameSiteMode.None y SameSiteMode.Lax, respectivamente.

Comportamiento nuevo

Todas las API afectadas tienen como valor predeterminado SameSiteMode.None.

Motivo del cambio

El valor predeterminado se ha cambiado para que SameSite fuera una característica de participación opcional.

Cada componente que emite cookies debe decidir si SameSite es adecuado para sus escenarios. Revise el uso de las API afectadas y vuelva a configurar SameSite según sea necesario.

Categoría

ASP.NET Core

API afectadas

HTTP: se ha deshabilitado la E/S sincrónica en todos los servidores

A partir de ASP.NET Core 3.0, las operaciones de servidor sincrónicas están deshabilitadas de forma predeterminada.

Descripción del cambio

AllowSynchronousIO es una opción en cada servidor que habilita o deshabilita las API de E/S sincrónicas, como HttpRequest.Body.Read, HttpResponse.Body.Write y Stream.Flush. Estas API han sido durante mucho tiempo una fuente de colapsos de subprocesos y de bloqueos de la aplicación. A partir de ASP.NET Core 3.0, versión preliminar 3, estas operaciones sincrónicas están deshabilitadas de forma predeterminada.

Servidores afectados:

  • Kestrel
  • HttpSys
  • IIS en proceso
  • TestServer

Se esperan errores parecidos a los siguientes:

  • Synchronous operations are disallowed. Call ReadAsync or set AllowSynchronousIO to true instead.
  • Synchronous operations are disallowed. Call WriteAsync or set AllowSynchronousIO to true instead.
  • Synchronous operations are disallowed. Call FlushAsync or set AllowSynchronousIO to true instead.

Cada servidor tiene una opción AllowSynchronousIO que controla este comportamiento y el valor predeterminado para todos ellos ahora es false.

El comportamiento también se puede invalidar en función de cada solicitud como una mitigación temporal. Por ejemplo:

var syncIOFeature = HttpContext.Features.Get<IHttpBodyControlFeature>();
if (syncIOFeature != null)
{
    syncIOFeature.AllowSynchronousIO = true;
}

Si tiene problemas con una elemento TextWriter u otra secuencia que llama a una API sincrónica en Dispose, llame a la nueva API de DisposeAsync en su lugar.

Para obtener información, vea dotnet/aspnetcore#7644.

Versión introducida

3.0

Comportamiento anterior

De manera predeterminada, solo se permitían HttpRequest.Body.Read, HttpResponse.Body.Write y Stream.Flush.

Comportamiento nuevo

Estas API sincrónicas no están permitidas de forma predeterminada:

Se esperan errores parecidos a los siguientes:

  • Synchronous operations are disallowed. Call ReadAsync or set AllowSynchronousIO to true instead.
  • Synchronous operations are disallowed. Call WriteAsync or set AllowSynchronousIO to true instead.
  • Synchronous operations are disallowed. Call FlushAsync or set AllowSynchronousIO to true instead.

Motivo del cambio

Estas API sincrónicas han sido durante mucho tiempo una fuente de colapsos de subprocesos y de bloqueos de la aplicación. A partir de ASP.NET Core 3.0, versión preliminar 3, las operaciones sincrónicas están deshabilitadas de forma predeterminada.

Use las versiones asincrónicas de los métodos. El comportamiento también se puede invalidar en función de cada solicitud como una mitigación temporal.

var syncIOFeature = HttpContext.Features.Get<IHttpBodyControlFeature>();
if (syncIOFeature != null)
{
    syncIOFeature.AllowSynchronousIO = true;
}

Categoría

ASP.NET Core

API afectadas

Identidad: se ha quitado la sobrecarga del método AddDefaultUI

A partir de ASP.NET Core 3.0, ya no existe la sobrecarga del método IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder,UIFramework).

Versión introducida

3.0

Motivo del cambio

Este cambio fue el resultado de la adopción de la característica de recursos web estáticos.

Llame a IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder) en lugar de a la sobrecarga que toma dos argumentos. Si usa Bootstrap 3, agregue también la línea siguiente a un elemento <PropertyGroup> del archivo de proyecto:

<IdentityUIFrameworkVersion>Bootstrap3</IdentityUIFrameworkVersion>

Categoría

ASP.NET Core

API afectadas

IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder,UIFramework)

Identidad: se ha cambiado la versión de Bootstrap predeterminada de la interfaz de usuario

A partir de ASP.NET Core 3.0, la interfaz de usuario de Identity tiene como valor predeterminado el uso de la versión 4 de Bootstrap.

Versión introducida

3.0

Comportamiento anterior

La llamada al método services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(); era la misma que en services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(UIFramework.Bootstrap3);.

Comportamiento nuevo

La llamada al método services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(); es la misma que en services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(UIFramework.Bootstrap4);.

Motivo del cambio

Bootstrap 4 se lanzó durante el periodo de tiempo de ASP.NET Core 3.0.

En el caso de que use la interfaz de usuario predeterminada de Identity y la haya agregado en Startup.ConfigureServices, este cambio le afectará, como se muestra en el ejemplo siguiente:

services.AddDefaultIdentity<IdentityUser>().AddDefaultUI();

Realice una de las siguientes acciones:

  • Migre su aplicación para usar Bootstrap 4 usando la guía de migración.

  • Actualice Startup.ConfigureServices para forzar el uso de Bootstrap 3. Por ejemplo:

    services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(UIFramework.Bootstrap3);

Categoría

ASP.NET Core

API afectadas

None

Identidad: SignInAsync produce una excepción para la identidad no autenticada

De forma predeterminada, SignInAsync produce una excepción para las entidades de seguridad o identidades en las que IsAuthenticated es false.

Versión introducida

3.0

Comportamiento anterior

SignInAsync acepta entidades de seguridad e identidades, incluidas las identidades en las que IsAuthenticated es false.

Comportamiento nuevo

De forma predeterminada, SignInAsync produce una excepción para las entidades de seguridad o identidades en las que IsAuthenticated es false. Hay una nueva marca para suprimir este comportamiento, pero el comportamiento predeterminado ha cambiado.

Motivo del cambio

El comportamiento anterior era problemático porque, de forma predeterminada, [Authorize] / RequireAuthenticatedUser() rechazó estas entidades de seguridad.

En ASP.NET Core 3.0, versión preliminar 6, hay una marca de RequireAuthenticatedSignIn en AuthenticationOptions que es true de forma predeterminada. Establezca esta marca en false para restaurar el comportamiento anterior.

Categoría

ASP.NET Core

API afectadas

None

Identidad: el constructor SignInManager acepta un nuevo parámetro

A partir de ASP.NET Core 3.0, se ha agregado un nuevo parámetro IUserConfirmation<TUser> al constructor SignInManager. Para obtener más información, consulte dotnet/aspnetcore#8356.

Versión introducida

3.0

Motivo del cambio

La motivación del cambio consistió en agregar compatibilidad con nuevos flujos de correo electrónico o de confirmación en Identity.

Si crea manualmente un elemento SignInManager, proporcione una implementación de IUserConfirmation o capte una de la inserción de dependencias que se va a proporcionar.

Categoría

ASP.NET Core

API afectadas

SignInManager<TUser>

Identidad: la interfaz de usuario usa la característica de recursos web estáticos

ASP.NET Core 3.0 ha presentado una característica de recursos web estáticos y la interfaz de usuario de Identity la ha adoptado.

Descripción del cambio

Como resultado de la interfaz de usuario de Identity que adopta la característica de recursos web estáticos:

  • La selección del marco se realiza mediante el uso de la propiedad IdentityUIFrameworkVersion en el archivo del proyecto.
  • Bootstrap 4 es el marco de la interfaz de usuario predeterminado para la interfaz de usuario de Identity. Bootstrap 3 ha alcanzado el final del ciclo de vida y debe considerar la posibilidad de migrar a una versión compatible.

Versión introducida

3.0

Comportamiento anterior

El marco de la interfaz de usuario predeterminado para la interfaz de usuario de Identity era Bootstrap 3. El marco de la interfaz de usuario se puede configurar mediante un parámetro para la llamada al método AddDefaultUI en Startup.ConfigureServices.

Comportamiento nuevo

El marco de la interfaz de usuario predeterminado para la interfaz de usuario de Identity es Bootstrap 4. El marco de la interfaz de usuario debe configurarse en el archivo del proyecto, en lugar de en la llamada al método AddDefaultUI.

Motivo del cambio

La adopción de la característica de recursos web estáticos requiere que la configuración del marco de la interfaz de usuario se mueva a MSBuild. La decisión sobre qué marco se debe insertar es una decisión en tiempo de compilación, no una decisión en runtime.

Revise la interfaz de usuario del sitio para garantizar que los nuevos componentes de Bootstrap 4 son compatibles. En caso necesario, use la propiedad IdentityUIFrameworkVersion de MSBuild para revertir a Bootstrap 3. Agregue la propiedad a un elemento <PropertyGroup> en el archivo del proyecto:

<IdentityUIFrameworkVersion>Bootstrap3</IdentityUIFrameworkVersion>

Categoría

ASP.NET Core

API afectadas

IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder, UIFramework)

Kestrel: se han quitado los adaptadores de conexión

Como parte de la migración de las API de "pubternal" a public, se ha quitado de Kestrel el concepto de un elemento IConnectionAdapter. Los adaptadores de conexión se han reemplazado por el middleware de conexión, que es similar al middleware HTTP en la canalización de ASP.NET Core, pero para conexiones de nivel inferior. HTTPS y el registro de conexiones se han movido de los adaptadores de conexión al middleware de conexión. Estos métodos de extensión deberían seguir funcionando sin problemas, pero los detalles de implementación han cambiado.

Para obtener más información, vea dotnet/aspnetcore#11412. Para obtener información, vea dotnet/aspnetcore#11475.

Versión introducida

3.0

Comportamiento anterior

Los componentes de extensibilidad de Kestrel se creaban mediante el uso de IConnectionAdapter.

Comportamiento nuevo

Los componentes de extensibilidad de Kestrel se crean como middleware.

Motivo del cambio

Este cambio está pensado para proporcionar una arquitectura de extensibilidad más flexible.

Convierta las implementaciones de IConnectionAdapter para usar el nuevo patrón de middleware, tal como se muestra aquí.

Categoría

ASP.NET Core

API afectadas

Microsoft.AspNetCore.Server.Kestrel.Core.Adapter.Internal.IConnectionAdapter

Kestrel: se ha quitado un ensamblado HTTPS vacío

Se ha quitado el ensamblado Microsoft.AspNetCore.Server.Kestrel.Https.

Versión introducida

3.0

Motivo del cambio

En ASP.NET Core 2.1, el contenido de Microsoft.AspNetCore.Server.Kestrel.Https se ha movido a Microsoft.AspNetCore.Server.Kestrel.Core. Este cambio se realizado de forma no interrumpida mediante el uso de atributos de [TypeForwardedTo].

  • Las bibliotecas que hacen referencia a Microsoft.AspNetCore.Server.Kestrel.Https 2.0 deben actualizar todas las dependencias de ASP.NET Core a 2.1 o una versión posterior. De lo contrario, se pueden interrumpir cuando se cargan en una aplicación ASP.NET Core 3.0.
  • Las aplicaciones y bibliotecas que tienen como destino ASP.NET Core 2.1 y versiones posteriores deben quitar las referencias directas al paquete NuGet Microsoft.AspNetCore.Server.Kestrel.Https.

Categoría

ASP.NET Core

API afectadas

None

Kestrel: se han movido los encabezados de finalizador de solicitud a una nueva recopilación

En versiones anteriores, Kestrel agregaba encabezados de finalizador fragmentados de HTTP/1.1 en la recopilación de encabezados de solicitud cuando el cuerpo de la solicitud se leía al final. Este comportamiento provocó problemas de ambigüedad entre encabezados y finalizadores. Se tomó la decisión de mover los finalizadores a una nueva recopilación.

Los finalizadores de solicitudes HTTP/2 no estaban disponibles en ASP.NET Core 2.2, pero ahora también están disponibles en esta nueva recopilación en ASP.NET Core 3.0.

Se han agregado métodos nuevos de extensión de solicitud para tener acceso a estos finalizadores.

Los finalizadores de HTTP/1.1 están disponibles una vez que se ha leído todo el cuerpo de la solicitud.

Los finalizadores de HTTP/2 están disponibles una vez que se han recibido del cliente. El cliente no enviará los finalizadores hasta que el servidor haya almacenado en búfer como mínimo el cuerpo de la solicitud completo. Es posible que deba leer el cuerpo de la solicitud para liberar espacio en búfer. Los finalizadores siempre están disponibles si lee el cuerpo de la solicitud hasta el final. Los finalizadores marcan el final del cuerpo.

Versión introducida

3.0

Comportamiento anterior

Los encabezados de finalizador de solicitud se agregarán a la recopilación HttpRequest.Headers.

Comportamiento nuevo

Los encabezados de finalizador de solicitud no están presentes en la recopilación HttpRequest.Headers. Use los métodos de extensión siguientes en HttpRequest para tener acceso a ellos:

  • GetDeclaredTrailers(): obtiene el encabezado de "finalizador" de la solicitud que muestra los finalizadores que se esperan después del cuerpo.
  • SupportsTrailers(): indica si la solicitud admite la recepción de encabezados de finalizador.
  • CheckTrailersAvailable(): determina si la solicitud admite finalizadores y si están disponible para lectura.
  • GetTrailer(string trailerName): obtiene el encabezado de finalización solicitado de la respuesta.

Motivo del cambio

Los finalizadores son una característica clave en escenarios como gRPC. Combinar los finalizadores en los encabezados de solicitud ha sido confuso para los usuarios.

Use los métodos de extensión relacionados con el finalizador en HttpRequest para tener acceso a los finalizadores.

Categoría

ASP.NET Core

API afectadas

HttpRequest.Headers

Kestrel: las abstracciones de transporte se han quitado y se han hecho públicas

Como parte del desplazamiento de las API de "pubternal", las API de la capa de transporte de Kestrel se exponen como una interfaz pública en la biblioteca de Microsoft.AspNetCore.Connections.Abstractions.

Versión introducida

3.0

Comportamiento anterior

  • Las abstracciones relacionadas con el transporte estaban disponibles en la biblioteca de Microsoft.AspNetCore.Server.Kestrel.Transport.Abstractions.
  • La propiedad ListenOptions.NoDelay estaba disponible.

Comportamiento nuevo

  • La interfaz de IConnectionListener se presentaba en la biblioteca de Microsoft.AspNetCore.Connections.Abstractions para exponer la funcionalidad más usada de la biblioteca de ...Transport.Abstractions.
  • NoDelay está ahora disponible en opciones de transporte (LibuvTransportOptions y SocketTransportOptions).
  • SchedulingMode ya no está disponible.

Motivo del cambio

ASP.NET Core 3.0 se ha desplazado de las API de "pubternal".

Categoría

ASP.NET Core

API afectadas

None

Localización: ResourceManagerWithCultureStringLocalizer y WithCulture se han marcado como obsoletos

La clase ResourceManagerWithCultureStringLocalizer y el miembro de interfaz WithCulture suelen ser fuentes de confusión para los usuarios de localización, en particular al crear su propia implementación de IStringLocalizer. Estos elementos proporcionan al usuario la impresión de que una instancia de IStringLocalizer es "por lenguaje y por recurso". En realidad, las instancias solo deben ser "por recurso". El lenguaje que se busca lo determina el CultureInfo.CurrentUICulture en tiempo de ejecución. Para eliminar el origen de la confusión, las API se han marcado como obsoletas en ASP.NET Core 3.0, versión preliminar 3. Las API se quitarán en una versión futura.

Para obtener el contexto, consulte dotnet/aspnetcore#3324. Para obtener información, vea dotnet/aspnetcore#7756.

Versión introducida

3.0

Comportamiento anterior

Los métodos no se marcaban como Obsolete.

Comportamiento nuevo

Los métodos se marcan como Obsolete.

Motivo del cambio

Las API representan un caso de uso que no se recomienda. Ha habido confusión sobre el diseño de la localización.

La recomendación es usar ResourceManagerStringLocalizer en su lugar. Permita que CurrentCulture establezca la referencia cultural. Si no es una opción, cree y use una copia de ResourceManagerWithCultureStringLocalizer.

Categoría

ASP.NET Core

API afectadas

Registro: la clase DebugLogger se ha convertido en interna

Antes de ASP.NET Core 3.0, el modificador de acceso de DebugLogger era public. En ASP.NET Core 3.0, el modificador de acceso se ha cambiado a internal.

Versión introducida

3.0

Motivo del cambio

El cambio se realiza para:

  • Aplicar la coherencia con otras implementaciones de registrador como ConsoleLogger.
  • Reducir la superficie de la API.

Use el método de extensión AddDebug de ILoggingBuilder para habilitar el registro de depuración. DebugLoggerProvider también sigue siendo public en caso de que el servicio se tenga que registrar de forma manual.

Categoría

ASP.NET Core

API afectadas

Microsoft.Extensions.Logging.Debug.DebugLogger

MVC: se ha recortado el sufijo Async de los nombres de acción de controlador

Como parte de la solución de dotnet/aspnetcore#4849, en ASP.NET Core MVC se recorta el sufijo Async de los nombres de acción de forma predeterminada. A partir de ASP.NET Core 3.0, este cambio afecta tanto al enrutamiento como a la generación de vínculos.

Versión introducida

3.0

Comportamiento anterior

Tenga en cuenta el siguiente controlador de ASP.NET Core MVC:

public class ProductController : Controller
{
    public async IActionResult ListAsync()
    {
        var model = await DbContext.Products.ToListAsync();
        return View(model);
    }
}

La acción es enrutable mediante Product/ListAsync. La generación de vínculos requiere que se especifique el sufijo Async. Por ejemplo:

<a asp-controller="Product" asp-action="ListAsync">List</a>

Comportamiento nuevo

En ASP.NET Core 3.0, la acción es enrutable mediante Product/List. El código de generación de vínculos debe omitir el sufijo Async. Por ejemplo:

<a asp-controller="Product" asp-action="List">List</a>

Este cambio no afecta a los nombres especificados mediante el atributo [ActionName]. El nuevo comportamiento se puede deshabilitar si se establece MvcOptions.SuppressAsyncSuffixInActionNames en false en Startup.ConfigureServices:

services.AddMvc(options =>
{
   options.SuppressAsyncSuffixInActionNames = false;
});

Motivo del cambio

Por convención, los métodos asincrónicos de .NET tienen el sufijo Async. Pero cuando un método define una acción de MVC, no es recomendable usar el sufijo Async.

Si la aplicación depende de que las acciones de MVC conserven el sufijo Async del nombre, elija una de las mitigaciones siguientes:

  • Use el atributo [ActionName] para conservar el nombre original.
  • Establezca MvcOptions.SuppressAsyncSuffixInActionNames en false en Startup.ConfigureServices para deshabilitar totalmente el cambio de nombre:
services.AddMvc(options =>
{
   options.SuppressAsyncSuffixInActionNames = false;
});

Categoría

ASP.NET Core

API afectadas

None

MVC: JsonResult se ha trasladado a Microsoft.AspNetCore.Mvc.Core

JsonResult se ha trasladado al ensamblado Microsoft.AspNetCore.Mvc.Core. Este tipo se ha usado para definirse en Microsoft.AspNetCore.Mvc.Formatters.Json. Se ha agregado un atributo [TypeForwardedTo] de nivel de ensamblado a Microsoft.AspNetCore.Mvc.Formatters.Json para solucionar este problema en la mayoría de los usuarios. Las aplicaciones que usan bibliotecas de terceros pueden encontrar problemas.

Versión introducida

3.0 Preview 6

Comportamiento anterior

Una aplicación que usa una biblioteca basada en la versión 2.2 se compila correctamente.

Comportamiento nuevo

Una aplicación que usa una biblioteca basada en la versión 2.2 produce un error en la compilación. Se proporciona un error que contiene una variación del texto siguiente:

The type 'JsonResult' exists in both 'Microsoft.AspNetCore.Mvc.Core, Version=3.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60' and 'Microsoft.AspNetCore.Mvc.Formatters.Json, Version=2.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'

Para obtener un ejemplo de este tipo de problema, consulte dotnet/aspnetcore#7220.

Motivo del cambio

Los cambios en el nivel de plataforma de la composición de ASP.NET Core como se describe en aspnet/Announcements#325.

Es posible que sea necesario volver a compilar las bibliotecas compiladas con la versión 2.2 de Microsoft.AspNetCore.Mvc.Formatters.Json para solucionar el problema de todos los consumidores. Si se ve afectado, póngase en contacto con el autor de la biblioteca. Solicite volver a compilar la biblioteca para tener como destino ASP.NET Core 3.0.

Categoría

ASP.NET Core

API afectadas

Microsoft.AspNetCore.Mvc.JsonResult

MVC: herramienta de precompilación en desuso

En ASP.NET Core 1.1, se presentó el paquete Microsoft.AspNetCore.Mvc.Razor.ViewCompilation (herramienta de precompilación MVC) para agregar compatibilidad con la compilación en tiempo de publicación de archivos Razor (archivos .cshtml). En ASP.NET Core 2.1, se presentó el SDK de Razor para ampliar las características de la herramienta de precompilación. El SDK de Razor agregaba compatibilidad con los archivos Razor en tiempo de compilación y publicación. El SDK comprueba la exactitud de los archivos .cshtml en tiempo de compilación mientras mejora el tiempo de inicio de la aplicación. El SDK de Razor está activado de forma predeterminada y no se requiere ningún gesto para empezar a usarlo.

En ASP.NET Core 3.0, se quitó la herramienta de precompilación MVC de ASP.NET Core 1.1. Las versiones anteriores del paquete seguirán recibiendo correcciones de seguridad y de errores importantes en la versión de revisión.

Versión introducida

3.0

Comportamiento anterior

El paquete Microsoft.AspNetCore.Mvc.Razor.ViewCompilation se usaba para compilar previamente las vistas de Razor de MVC.

Comportamiento nuevo

El SDK de Razor es compatible de forma nativa con esta funcionalidad. El paquete Microsoft.AspNetCore.Mvc.Razor.ViewCompilation ya no está actualizado.

Motivo del cambio

El SDK de Razor proporciona más funcionalidad y comprueba la exactitud de los archivos .cshtml en tiempo de compilación. El SDK también mejora el tiempo de inicio de la aplicación.

Para los usuarios de ASP.NET Core 2.1 o versiones posteriores, actualice para usar la compatibilidad nativa con la precompilación en el SDK de Razor. Si los errores o las características que faltan impiden la migración al SDK de Razor, abra una incidencia en dotnet/aspnetcore.

Categoría

ASP.NET Core

API afectadas

None

MVC: los tipos "pubternal" se han cambiado a internal

En ASP.NET Core 3.0, todos los tipos "pubternal" de MVC se actualizaron para ser public en un espacio de nombres compatible o internal, según correspondiera.

Descripción del cambio

In ASP.NET Core, los tipos "pubternal" se declaran como public pero residen en un espacio de nombres con un sufijo .Internal. Aunque estos tipos son public, no tienen ninguna directiva compatible y están sujetos a cambios importantes. Desafortunadamente, el uso accidental de estos tipos es habitual, lo que da lugar a cambios importantes en estos proyectos y limita la capacidad de mantener el marco.

Versión introducida

3.0

Comportamiento anterior

Algunos tipos de MVC eran public pero en un espacio de nombres .Internal. Estos tipos no tenían ninguna directiva compatible y estaban sujetos a cambios importantes.

Comportamiento nuevo

Todos estos tipos se actualizan para ser public en un espacio de nombres compatible o que se marquen como internal.

Motivo del cambio

El uso accidental de los tipos "pubternal" es habitual, lo que da lugar a cambios importantes en estos proyectos y limita la capacidad de mantener el marco.

Si usa tipos que se han convertido realmente en public y se han movido a un nuevo espacio de nombres compatible, actualice las referencias para que coincidan con los espacios de nombres nuevos.

Si utiliza tipos que se han marcado como internal, deberá buscar una alternativa. Los tipos "pubternal" anteriores nunca se admitieron para uso público. Si hay tipos específicos en estos espacios de nombres que son fundamentales para las aplicaciones, registre una incidencia en dotnet/aspnetcore. Se pueden pensar ideas para hacer los tipos solicitados public.

Categoría

ASP.NET Core

API afectadas

Este cambio incluye tipos en los espacios de nombres siguientes:

  • Microsoft.AspNetCore.Mvc.Cors.Internal
  • Microsoft.AspNetCore.Mvc.DataAnnotations.Internal
  • Microsoft.AspNetCore.Mvc.Formatters.Internal
  • Microsoft.AspNetCore.Mvc.Formatters.Json.Internal
  • Microsoft.AspNetCore.Mvc.Formatters.Xml.Internal
  • Microsoft.AspNetCore.Mvc.Internal
  • Microsoft.AspNetCore.Mvc.ModelBinding.Internal
  • Microsoft.AspNetCore.Mvc.Razor.Internal
  • Microsoft.AspNetCore.Mvc.RazorPages.Internal
  • Microsoft.AspNetCore.Mvc.TagHelpers.Internal
  • Microsoft.AspNetCore.Mvc.ViewFeatures.Internal

MVC: se han quitado las correcciones de compatibilidad (shim) con la API web

A partir de ASP.NET Core 3.0, el paquete Microsoft.AspNetCore.Mvc.WebApiCompatShim ya no está disponible.

Descripción del cambio

El paquete Microsoft.AspNetCore.Mvc.WebApiCompatShim (WebApiCompatShim) proporciona compatibilidad parcial en ASP.NET Core con ASP.NET 4.x Web API 2 para simplificar la migración de implementaciones existentes de API web a ASP.NET Core. Pero las aplicaciones que usan WebApiCompatShim no se benefician de las características relacionadas con la API que se distribuyen en versiones recientes de ASP.NET Core. Estas características incluyen la generación mejorada de especificaciones de Open API, el control de errores estandarizado y la generación de código de cliente. Para centrar mejor los esfuerzos de API en la versión 3.0, se ha quitado WebApiCompatShim. Las aplicaciones existentes en las que se usa WebApiCompatShim se deben migrar al modelo de [ApiController] más reciente.

Versión introducida

3.0

Motivo del cambio

La corrección de compatibilidad (shim) de la API web era una herramienta de migración. Restringe el acceso de los usuarios a la nueva funcionalidad agregada en ASP.NET Core.

Quite el uso de esta corrección de compatibilidad y migre directamente a la funcionalidad similar en ASP.NET Core.

Categoría

ASP.NET Core

API afectadas

Microsoft.AspNetCore.Mvc.WebApiCompatShim

Razor: API RazorTemplateEngine eliminada

Se ha quitado la API RazorTemplateEngine y se ha reemplazado por Microsoft.AspNetCore.Razor.Language.RazorProjectEngine.

Para obtener información, vea la incidencia de GitHub dotnet/aspnetcore#25215.

Versión introducida

3.0

Comportamiento anterior

Un motor de plantillas se puede crear y usar para analizar y generar código para archivos de Razor.

Comportamiento nuevo

Se puede crear RazorProjectEngine y se le puede proporcionar el mismo tipo de información que a RazorTemplateEngine para analizar y generar código para archivos de Razor. RazorProjectEngine también proporciona niveles de configuración adicionales.

Motivo del cambio

RazorTemplateEngine estaba demasiado acoplado a las implementaciones existentes. Este acoplamiento tan estrecho daba lugar a más preguntas al intentar configurar correctamente una canalización de análisis y generación de Razor.

Use RazorProjectEngine en lugar de RazorTemplateEngine. Considere los ejemplos siguientes.

Creación y configuración de RazorProjectEngine
RazorProjectEngine projectEngine =
    RazorProjectEngine.Create(RazorConfiguration.Default,
        RazorProjectFileSystem.Create(@"C:\source\repos\ConsoleApp4\ConsoleApp4"),
        builder =>
        {
            builder.ConfigureClass((document, classNode) =>
            {
                classNode.ClassName = "MyClassName";

                // Can also configure other aspects of the class here.
            });

            // More configuration can go here
        });
Generación de código para un archivo de Razor
RazorProjectItem item = projectEngine.FileSystem.GetItem(
    @"C:\source\repos\ConsoleApp4\ConsoleApp4\Example.cshtml",
    FileKinds.Legacy);
RazorCodeDocument output = projectEngine.Process(item);

// Things available
RazorSyntaxTree syntaxTree = output.GetSyntaxTree();
DocumentIntermediateNode intermediateDocument =
    output.GetDocumentIntermediateNode();
RazorCSharpDocument csharpDocument = output.GetCSharpDocument();

Categoría

ASP.NET Core

API afectadas

  • RazorTemplateEngine
  • RazorTemplateEngineOptions

Razor: la compilación en tiempo de ejecución se ha movido a un paquete

La compatibilidad con la compilación en entorno de ejecución de las vistas de Razor y Razor Pages se ha movido a un paquete independiente.

Versión introducida

3.0

Comportamiento anterior

La compilación en entorno de ejecución está disponible sin necesidad de paquetes adicionales.

Comportamiento nuevo

La funcionalidad se ha pasado al paquete Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation.

Las siguientes API estaban disponibles anteriormente en Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions para admitir la compilación en entorno de ejecución. Las API ahora están disponibles mediante Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation.MvcRazorRuntimeCompilationOptions.

  • RazorViewEngineOptions.FileProviders ahora es MvcRazorRuntimeCompilationOptions.FileProviders
  • RazorViewEngineOptions.AdditionalCompilationReferences ahora es MvcRazorRuntimeCompilationOptions.AdditionalReferencePaths

Además, se ha quitado Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions.AllowRecompilingViewsOnFileChange. La recompilación en los cambios de archivo está habilitada de forma predeterminada al hacer referencia al paquete Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation.

Motivo del cambio

Este cambio era necesario para quitar la dependencia de marco compartido de ASP.NET Core en Roslyn.

Las aplicaciones que requieren la compilación o recompilación en entorno de ejecución de archivos Razor deben realizar los pasos siguientes:

  1. Agregar una referencia al paquete Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation.

  2. Actualizar el método Startup.ConfigureServices del proyecto para incluir una llamada a AddRazorRuntimeCompilation. Por ejemplo:

    services.AddMvc()
    .AddRazorRuntimeCompilation();

Categoría

ASP.NET Core

API afectadas

Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions

Estado de sesión: se han quitado las API obsoletas

Se han quitado las API obsoletas para configurar las cookies de sesión. Para obtener más información, consulte aspnet/Announcements#257.

Versión introducida

3.0

Motivo del cambio

Este cambio exige coherencia entre las API para configurar las características que usan cookies.

Migre el uso de las API quitadas a sus reemplazos más recientes. Considere el ejemplo siguiente de Startup.ConfigureServices:

public void ConfigureServices(ServiceCollection services)
{
    services.AddSession(options =>
    {
        // Removed obsolete APIs
        options.CookieName = "SessionCookie";
        options.CookieDomain = "contoso.com";
        options.CookiePath = "/";
        options.CookieHttpOnly = true;
        options.CookieSecure = CookieSecurePolicy.Always;

        // new API
        options.Cookie.Name = "SessionCookie";
        options.Cookie.Domain = "contoso.com";
        options.Cookie.Path = "/";
        options.Cookie.HttpOnly = true;
        options.Cookie.SecurePolicy = CookieSecurePolicy.Always;
    });
}

Categoría

ASP.NET Core

API afectadas

Marco compartido: se han quitado los ensamblados de Microsoft.AspNetCore.App

A partir de ASP.NET Core 3.0, el marco compartido de ASP.NET Core (Microsoft.AspNetCore.App) solo contiene ensamblados propios totalmente desarrollados, admitidos y mantenidos por Microsoft.

Descripción del cambio

Considere el cambio como la redefinición de los límites de la "plataforma" ASP.NET. A través de GitHub, cualquier usuario puede compilar el código fuente del marco compartido y seguirá ofreciendo a las aplicaciones las ventajas existentes de los marcos compartidos de .NET Core. Algunas ventajas son el tamaño de implementación más pequeño, la revisión centralizada y el tiempo de inicio más rápido.

Como parte del cambio, en Microsoft.AspNetCore.App se han introducido algunos cambios importantes.

Versión introducida

3.0

Comportamiento anterior

Los proyectos hacían referencia a Microsoft.AspNetCore.App mediante un elemento <PackageReference> en el archivo de proyecto.

Además, Microsoft.AspNetCore.App incluía los subcomponentes siguientes:

  • Json.NET (Newtonsoft.Json)
  • Entity Framework Core (ensamblados con el prefijo Microsoft.EntityFrameworkCore.)
  • Roslyn (Microsoft.CodeAnalysis)

Comportamiento nuevo

Una referencia a Microsoft.AspNetCore.App ya no requiere un elemento <PackageReference> en el archivo de proyecto. El SDK de .NET Core admite un nuevo elemento denominado <FrameworkReference>, que reemplaza el uso de <PackageReference>.

Para obtener más información, vea dotnet/aspnetcore#3612.

Entity Framework Core se distribuye como paquetes NuGet. Este cambio alinea el modelo de envío con el resto de las bibliotecas de acceso a datos de .NET. Proporciona a Entity Framework Core la ruta más sencilla para continuar con la innovación al tiempo que admite las distintas plataformas .NET. La exclusión de Entity Framework Core del marco compartido no tiene ningún impacto en su estado como biblioteca desarrollada, admitida y mantenida por Microsoft. Continúa bajo la cobertura de la directiva de compatibilidad de .NET Core.

Json.NET y Entity Framework Core siguen funcionando con ASP.NET Core. Pero no se incluirán en el marco compartido.

Para obtener más información, vea El futuro de JSON en .NET Core 3.0. Vea también la lista completa de archivos binarios que se han quitado del marco compartido.

Motivo del cambio

Este cambio simplifica el consumo de Microsoft.AspNetCore.App y reduce la duplicación entre paquetes NuGet y marcos compartidos.

Para obtener más información sobre la motivación de este cambio, vea esta entrada de blog.

A partir de ASP.NET Core 3.0, ya no es necesario que los proyectos consuman ensamblados en Microsoft.AspNetCore.App como paquetes NuGet. Para simplificar la selección como destino y el uso del marco compartido de ASP.NET Core, ya no se generan muchos paquetes NuGet enviados desde ASP.NET Core 1.0. Las API que proporcionan esos paquetes siguen estando disponibles para las aplicaciones mediante el uso de un elemento <FrameworkReference> para Microsoft.AspNetCore.App. Entre los ejemplos de API comunes se incluyen Kestrel, MVC y Razor.

Este cambio no se aplica a todos los archivos binarios a los que se hace referencia a través de Microsoft.AspNetCore.App en ASP.NET Core 2.x. Entre las excepciones destacables se incluyen las siguientes:

  • Las bibliotecas de Microsoft.Extensions que todavía tienen .NET Standard como destino están disponibles como paquetes NuGet (vea https://github.com/dotnet/extensions).
  • API generadas por el equipo de ASP.NET Core que no forman parte de Microsoft.AspNetCore.App. Por ejemplo, los componentes siguientes están disponibles como paquetes NuGet:
  • Extensiones para MVC que mantienen la compatibilidad con Json.NET. Se proporciona una API como paquete NuGet para admitir el uso de Json.NET y MVC. Consulte la guía de migración de ASP.NET Core para obtener más detalles.
  • El cliente .NET de SignalR mantiene la compatibilidad con .NET Standard y se incluye como paquete NuGet. Está diseñado para usarse en muchos entornos de ejecución de .NET, como Xamarin y UWP.

Para obtener más información, vea Detección de la generación de paquetes para ensamblados de marco compartido en 3.0. Para obtener información, vea dotnet/aspnetcore#3757.

Categoría

ASP.NET Core

API afectadas

Marco compartido: se ha eliminado Microsoft.AspNetCore.All

A partir de ASP.NET Core 3.0, ya no se generan el metapaquete Microsoft.AspNetCore.All y el marco compartido Microsoft.AspNetCore.All correspondiente. Este paquete está disponible en ASP.NET Core 2.2 y seguirá recibiendo actualizaciones de mantenimiento en ASP.NET Core 2.1.

Versión introducida

3.0

Comportamiento anterior

Las aplicaciones podían usar el metapaquete Microsoft.AspNetCore.All para seleccionar como destino el marco compartido Microsoft.AspNetCore.All en .NET Core.

Comportamiento nuevo

En .NET Core 3.0 no se incluye un marco compartido Microsoft.AspNetCore.All.

Motivo del cambio

En el metapaquete Microsoft.AspNetCore.All se incluía un gran número de dependencias externas.

Migre el proyecto para usar el marco Microsoft.AspNetCore.App. Los componentes que anteriormente estaban disponibles en Microsoft.AspNetCore.All lo siguen estando en NuGet. Ahora esos componentes se implementan con la aplicación en lugar de incluirse en el marco compartido.

Categoría

ASP.NET Core

API afectadas

None

SignalR: se ha reemplazado HandshakeProtocol.SuccessHandshakeData

El campo HandshakeProtocol.SuccessHandshakeData se ha quitado y se ha reemplazado por un método auxiliar que genera una respuesta de protocolo de enlace correcta dado un protocolo IHubProtocol específico.

Versión introducida

3.0

Comportamiento anterior

HandshakeProtocol.SuccessHandshakeData era un campo public static ReadOnlyMemory<byte>.

Comportamiento nuevo

HandshakeProtocol.SuccessHandshakeData se ha reemplazado por un método GetSuccessfulHandshake(IHubProtocol protocol)static que devuelve un objeto ReadOnlyMemory<byte> basado en el protocolo especificado.

Motivo del cambio

Se han agregado campos adicionales a la respuesta del protocolo de enlace que no son constantes y cambian en función del protocolo seleccionado.

Ninguno. Este tipo no está diseñado para su uso desde el código de usuario. Es public, por lo que se puede compartir entre el servidor de SignalR y el cliente. También lo pueden usar clientes de SignalR personalizados escritos en .NET. Los usuarios de SignalR no deberían verse afectados por este cambio.

Categoría

ASP.NET Core

API afectadas

HandshakeProtocol.SuccessHandshakeData

SignalR: se han quitado los métodos ResetSendPing y ResetTimeout de HubConnection

Los métodos ResetSendPing y ResetTimeout se han quitado de la API HubConnection de SignalR. Estos métodos se diseñaron originalmente solo para uso interno, pero se hicieron públicos en ASP.NET Core 2.2. Estos métodos no estarán disponibles a partir de ASP.NET Core 3.0, versión preliminar 4. Para obtener información, vea dotnet/aspnetcore#8543.

Versión introducida

3.0

Comportamiento anterior

Las API estaban disponibles.

Comportamiento nuevo

Las API se quitan.

Motivo del cambio

Estos métodos se diseñaron originalmente solo para uso interno, pero se hicieron públicos en ASP.NET Core 2.2.

No use estos métodos.

Categoría

ASP.NET Core

API afectadas

SignalR: se han cambiado los constructores de HubConnectionContext

Los constructores de HubConnectionContext de SignalR han cambiado para aceptar un tipo de opciones, en lugar de varios parámetros, para agregar opciones con garantía de futuro. Este cambio reemplaza dos constructores por un único constructor que acepta un tipo de opciones.

Versión introducida

3.0

Comportamiento anterior

HubConnectionContext tiene dos constructores:

public HubConnectionContext(ConnectionContext connectionContext, TimeSpan keepAliveInterval, ILoggerFactory loggerFactory);
public HubConnectionContext(ConnectionContext connectionContext, TimeSpan keepAliveInterval, ILoggerFactory loggerFactory, TimeSpan clientTimeoutInterval);

Comportamiento nuevo

Los dos constructores se han quitado y se han reemplazado por uno:

public HubConnectionContext(ConnectionContext connectionContext, HubConnectionContextOptions contextOptions, ILoggerFactory loggerFactory)

Motivo del cambio

El nuevo constructor usa un nuevo objeto de opciones. Por tanto, las características de HubConnectionContext se pueden expandir en el futuro sin crear más constructores y cambios importantes.

En lugar de usar el constructor siguiente:

HubConnectionContext connectionContext = new HubConnectionContext(
    connectionContext,
    keepAliveInterval: TimeSpan.FromSeconds(15),
    loggerFactory,
    clientTimeoutInterval: TimeSpan.FromSeconds(15));

Use el constructor siguiente:

HubConnectionContextOptions contextOptions = new HubConnectionContextOptions()
{
    KeepAliveInterval = TimeSpan.FromSeconds(15),
    ClientTimeoutInterval = TimeSpan.FromSeconds(15)
};
HubConnectionContext connectionContext = new HubConnectionContext(connectionContext, contextOptions, loggerFactory);

Categoría

ASP.NET Core

API afectadas

SignalR: se ha cambiado el nombre del paquete de cliente de JavaScript

En ASP.NET Core 3.0, versión preliminar 7, el nombre del paquete de cliente de JavaScript de SignalR ha cambiado de @aspnet/signalr a @microsoft/signalr. El cambio de nombre refleja el hecho de que SignalR es útil más allá de las aplicaciones de ASP.NET Core, gracias a Azure SignalR Service.

Para reaccionar a este cambio, cambie las referencias en los archivos package.json, las instrucciones require y las instrucciones import de ECMAScript. No se cambiará ninguna API como parte de este cambio de nombre.

Para obtener información, vea dotnet/aspnetcore#11637.

Versión introducida

3.0

Comportamiento anterior

El paquete de cliente se llamaba @aspnet/signalr.

Comportamiento nuevo

El paquete de cliente se llama @microsoft/signalr.

Motivo del cambio

El cambio de nombre clarifica que SignalR es útil más allá de las aplicaciones de ASP.NET Core, gracias a Azure SignalR Service.

Cambie al paquete @microsoft/signalr nuevo.

Categoría

ASP.NET Core

API afectadas

None

SignalR: los métodos UseSignalR y UseConnections se han marcado como obsoletos

Los métodos UseConnections y UseSignalR, y las clases ConnectionsRouteBuilder y HubRouteBuilder están marcados como obsoletos en ASP.NET Core 3.0.

Versión introducida

3.0

Comportamiento anterior

El enrutamiento del centro de conectividad de SignalR se configuraba mediante UseSignalR o UseConnections.

Comportamiento nuevo

La forma antigua de configurar el enrutamiento ha quedado obsoleta y se ha reemplazado por el enrutamiento del punto de conexión.

Motivo del cambio

El middleware se está trasladando al sistema de enrutamiento nuevo de puntos de conexión. La forma anterior de agregar middleware está obsoleta.

Reemplace UseSignalR por UseEndpoints:

Código anterior:

app.UseSignalR(routes =>
{
    routes.MapHub<SomeHub>("/path");
});

Código nuevo:

app.UseEndpoints(endpoints =>
{
    endpoints.MapHub<SomeHub>("/path");
});

Categoría

ASP.NET Core

API afectadas

SPA: SpaServices y NodeServices se han marcado como obsoletos

El contenido de los siguientes paquetes NuGet no es necesario a partir de ASP.NET Core 2.1. Por lo tanto, los paquetes siguientes se marcan como obsoletos:

Por el mismo motivo, los módulos siguientes npm se han marcado como en desuso:

Los paquetes y módulos npm anteriores se quitarán más adelante en .NET 5.

Versión introducida

3.0

Comportamiento anterior

Los paquetes y módulos npm en desuso se diseñaron para integrar ASP.NET Core con varios marcos de aplicación de página única (SPA). Estos marcos incluyen React, and React con Redux.

Comportamiento nuevo

Existe un nuevo mecanismo de integración en el paquete de NuGet Microsoft.AspNetCore.SpaServices.Extensions. El paquete sigue siendo la base de las plantillas de proyecto Angular y React a partir de ASP.NET Core 2.1.

Motivo del cambio

ASP.NET Core admite la integración con varios marcos de aplicación de página única (SPA), como Angular, React y React con Redux. Inicialmente, la integración con estos marcos se logró con componentes específicos de ASP.NET Core que administraban escenarios como la representación previa y la integración del lado servidor con Webpack. Con el paso del tiempo, los estándares del sector cambiaron. Cada uno de los marcos de SPA lanzó sus propias interfaces de línea de comandos estándar. Por ejemplo, la CLI de Angular y create-react-app.

Cuando se publicó ASP.NET Core 2.1 en mayo de 2018, el equipo respondió al cambio en los estándares. Se proporcionó una manera más nueva y sencilla de integrarse con las cadenas de herramientas propias de los marcos de SPA. El nuevo mecanismo de integración existe en el paquete Microsoft.AspNetCore.SpaServices.Extensions y sigue siendo la base de las plantillas de proyecto Angular y React a partir de ASP.NET Core 2.1.

Para aclarar que los componentes específicos de ASP.NET Core antiguos son irrelevantes y no se recomiendan, se realizan las acciones siguientes:

  • El mecanismo de integración anterior a la versión 2.1 está marcado como obsoleto.
  • Los paquetes npm compatibles se marcan como en desuso.

Si usa estos paquetes, actualice las aplicaciones para usar la funcionalidad:

  • En el paquete Microsoft.AspNetCore.SpaServices.Extensions.
  • Que proporcionan los marcos de SPA que está usando.

Para habilitar características como la representación previa del lado servidor y la recarga de módulos frecuentes, consulte la documentación del marco de SPA correspondiente. La funcionalidad de Microsoft.AspNetCore.SpaServices.Extensionsno está obsoleta y seguirá siendo compatible.

Categoría

ASP.NET Core

API afectadas

SPA: SpaServices y NodeServices ya no vuelven al registrador de la consola

Microsoft.AspNetCore.SpaServices y Microsoft.AspNetCore.NodeServices no mostrarán los registros de la consola a menos que el registro esté configurado.

Versión introducida

3.0

Comportamiento anterior

Antes, Microsoft.AspNetCore.SpaServices y Microsoft.AspNetCore.NodeServices creaban de forma automática un registrador de consola cuando el registro no estaba configurado.

Comportamiento nuevo

Microsoft.AspNetCore.SpaServices y Microsoft.AspNetCore.NodeServices no mostrarán los registros de la consola a menos que el registro esté configurado.

Motivo del cambio

Existe la necesidad de alinearse con el modo de implementar el registro en otros paquetes de ASP.NET Core.

Si se requiere el comportamiento anterior, agregue services.AddLogging(builder => builder.AddConsole()) al método Setup.ConfigureServices para configurar el registro de la consola.

Categoría

ASP.NET Core

API afectadas

None

Plataforma de destino: se ha quitado la compatibilidad con .NET Framework

A partir de ASP.NET Core 3.0, .NET Framework es un marco de destino que no se admite.

Descripción del cambio

.NET Framework 4.8 es la última versión principal de .NET Framework. Las nuevas aplicaciones de ASP.NET Core se deben compilar en .NET Core. A partir de NET Core 3.0, puede considerar a ASP.NET Core 3.0 una parte de .NET Core.

Los clientes que usen ASP.NET Core con .NET Framework pueden continuar utilizando la versión 2.1 LTS de forma totalmente compatible. La compatibilidad y el servicio para la versión 2.1 continuarán hasta el 21 de agosto de 2021. Esta fecha es tres años posterior a la declaración de la versión LTS de acuerdo a la Directiva de compatibilidad de .NET. La compatibilidad con los paquetes de ASP.NET Core 2.1 en .NET Framework se extenderá indefinidamente, de forma similar a la directiva de servicio para otros marcos de ASP.NET basados en paquetes.

Para más información sobre cómo migrar de .NET Framework a .NET Core, vea Portabilidad a .NET Core.

Los paquetes Microsoft.Extensions (como el registro, la inserción de dependencias y la configuración) y Entity Framework Core no se ven afectados. Seguirán admitiendo .NET Standard.

Para más información sobre la motivación de este cambio, vea la entrada de blog original.

Versión introducida

3.0

Comportamiento anterior

Las aplicaciones ASP.NET Core se podían ejecutar en .NET Core o .NET Framework.

Comportamiento nuevo

Las aplicaciones ASP.NET Core solo se pueden ejecutar en .NET Core.

Realice una de las siguientes acciones:

  • Mantenga la aplicación en ASP.NET Core 2.1.
  • Migre la aplicación y las dependencias a .NET Core.

Categoría

ASP.NET Core

API afectadas

None

Bibliotecas de Core .NET

Las API que notifican la versión ahora notifican la versión del producto y no la del archivo

Muchas de las API que devuelven versiones en .NET Core ahora devuelven la versión del producto en lugar de la del archivo.

Descripción del cambio

En .NET Core 2.2 y en versiones anteriores, métodos como Environment.Version y RuntimeInformation.FrameworkDescription, y el cuadro de diálogo de las propiedades del archivo para los ensamblados de .NET Core reflejan la versión del archivo. A partir de .NET Core 3.0, reflejan la versión del producto.

En la ilustración siguiente se muestra la diferencia en la información sobre la versión del ensamblado System.Runtime.dll para .NET Core 2.2 (a la izquierda) y .NET Core 3.0 (a la derecha), tal y como se muestra en los cuadros de diálogo de las propiedades del archivo de Windows Explorer.

Difference in product version information

Versión introducida

3.0

Ninguno. Este cambio debería hacer que la comprobación de la versión sea intuitiva en lugar de difícil de entender.

Categoría

Bibliotecas de Core .NET

API afectadas

No se puede recurrir de formar recursiva a las instancias personalizadas de EncoderFallbackBuffer

No se puede recurrir de formar recursiva a las instancias personalizadas de EncoderFallbackBuffer. La implementación de EncoderFallbackBuffer.GetNextChar() debe traducirse en una secuencia de caracteres que se pueda convertir a la codificación de destino. De lo contrario, se produce una excepción.

Descripción del cambio

Durante una operación de transcodificación de caracteres a bytes, el runtime detecta secuencias UTF-16 de formato incorrecto o no convertibles y proporciona esos caracteres al método EncoderFallbackBuffer.Fallback. El método Fallback determina los caracteres que han de sustituirse por los datos originales no convertibles y estos caracteres se drenan llamando a EncoderFallbackBuffer.GetNextChar en un bucle.

El runtime intenta luego transcodificar estos caracteres de sustitución en la codificación de destino. Si esta operación se realiza correctamente, el runtime continúa con la transcodificación desde donde se quedó en la cadena de entrada original.

Antes, las implementaciones personalizadas de EncoderFallbackBuffer.GetNextChar() pueden devolver secuencias de caracteres que no se pueden convertir en la codificación de destino. Si los caracteres sustituidos no se pueden transcodificar en la codificación de destino, el runtime vuelve a invocar el método EncoderFallbackBuffer.Fallback con los caracteres de sustitución, esperando que el método EncoderFallbackBuffer.GetNextChar() devuelva una nueva secuencia de sustitución. Este proceso continúa hasta que el runtime ve finalmente una sustitución convertible de formato correcto o hasta que se alcanza un número máximo de repeticiones.

A partir de .NET Core 3.0, las implementaciones personalizadas de EncoderFallbackBuffer.GetNextChar() deben devolver secuencias de caracteres que se pueden convertir en la codificación de destino. Si los caracteres sustituidos no se pueden transcodificar en la codificación de destino, se produce una ArgumentException. El runtime ya no realizará llamadas recursivas a la instancia de EncoderFallbackBuffer.

Este comportamiento solo se aplica cuando se cumplen las tres condiciones siguientes:

  • El runtime detecta una secuencia UTF-16 de formato incorrecto o una secuencia UTF-16 que no se puede convertir en la codificación de destino.
  • Se ha especificado un EncoderFallback personalizado.
  • El EncoderFallback personalizado intenta sustituir una nueva secuencia UTF-16 con formato incorrecto o no convertible.

Versión introducida

3.0

La mayoría de los desarrolladores no tienen que realizar ninguna acción.

Si una aplicación usa un objeto EncoderFallback personalizado con una clase EncoderFallbackBuffer, asegúrese de que la implementación de EncoderFallbackBuffer.Fallback rellena el búfer de reserva con datos UTF-16 de formato correcto que se puedan convertir directamente en la codificación de destino cuando el runtime invoque por primera vez el método Fallback.

Categoría

Bibliotecas de Core .NET

API afectadas

Cambios en los comportamientos de formato y análisis de los números de punto flotante

Los comportamientos de formato y análisis de los números de punto flotante (de los tipos Double y Single) ahora son compatibles con IEEE. Esto garantiza que el comportamiento de los tipos de punto flotante en .NET coincide con el de otros lenguajes compatibles con IEEE. Por ejemplo, double.Parse("SomeLiteral") siempre debe coincidir con lo que C# genera para double x = SomeLiteral.

Descripción del cambio

En .NET Core 2.2 y en versiones anteriores, dar formato con Double.ToString y Single.ToString, y realizar análisis con Double.Parse, Double.TryParse, Single.Parse y Single.TryParse no es compatible con IEEE. Como resultado, no es posible garantizar que un valor realizará todo el proceso con una cadena de formato estándar o personalizado compatible. En algunas entradas, se puede producir un error al intentar analizar un valor con formato y, en otras, el valor analizado no es igual que el valor original.

A partir de .NET Core 3.0, las operaciones de análisis y formato de punto flotante son compatibles con IEEE 754.

En la tabla siguiente se muestran dos fragmentos de código y cómo cambia la salida entre .NET Core2.2 y .NET Core 3.1.

Fragmento de código Salida en .NET Core 2.2 Salida en .NET Core 3.1
Console.WriteLine((-0.0).ToString()); 0 -0
var value = -3.123456789123456789;
Console.WriteLine(value == double.Parse(value.ToString()));		 False True

Para obtener más información, vea la entrada de blog Mejoras de formato y análisis de punto flotante en .NET Core 3.0.

Versión introducida

3.0

La sección Impacto potencial en el código existente de la entrada de blog Mejoras en el análisis y el formato de los puntos flotantes en .NET Core 3.0 sugiere algunos cambios que puede hacer en su código si desea mantener el comportamiento anterior.

  • Para algunas diferencias de formato, puede obtener un comportamiento equivalente al anterior especificando una cadena de formato diferente.
  • En el caso de las diferencias de análisis, no hay ningún mecanismo para volver al comportamiento anterior.

Categoría

Bibliotecas de Core .NET

API afectadas

Las operaciones de análisis de punto flotante ya no producen un error o lanzan una excepción OverflowException

Los métodos de análisis de punto flotante ya no lanzan una OverflowException o devuelven false cuando analizan una cadena cuyo valor numérico está fuera del rango del tipo de punto flotante Single o Double.

Descripción del cambio

En .NET Core 2.2 y versiones anteriores, los métodos Double.Parse y Single.Parse lanzan una OverflowException para los valores que se encuentran fuera del rango de su tipo respectivo. Los métodos Double.TryParse y Single.TryParse devuelven false para las representaciones de cadena de valores numéricos fuera del rango.

A partir de .NET Core 3.0, los métodos Double.Parse, Double.TryParse, Single.Parse y Single.TryParse ya no producen errores al analizar cadenas numéricas fuera del rango. En su lugar, los métodos de análisis de Double devuelven Double.PositiveInfinity para los valores que superan Double.MaxValue y Double.NegativeInfinity para los valores menores que Double.MinValue. Del mismo modo, los métodos de análisis de Single devuelven Single.PositiveInfinity para los valores que superan Single.MaxValue y Single.NegativeInfinity para los valores menores que Single.MinValue.

Este cambio se ha realizado para mejorar el cumplimiento de la norma IEEE 754:2008.

Versión introducida

3.0

Este cambio puede afectar al código de alguna de estas dos formas:

  • El código depende del controlador para que OverflowException se ejecute cuando se produce un desbordamiento. En este caso, debe quitar la instrucción catch y colocar cualquier código necesario en una instrucción If que compruebe si Double.IsInfinity o Single.IsInfinity es true.

  • El código presupone que los valores de punto flotante no son Infinity. En este caso, debe agregar el código necesario para comprobar los valores de punto flotante de PositiveInfinity y NegativeInfinity.

Categoría

Bibliotecas de Core .NET

API afectadas

Se ha movido InvalidAsynchronousStateException a otro ensamblado

La clase InvalidAsynchronousStateException se ha movido.

Descripción del cambio

En .NET Core 2.2 y en versiones anteriores, la clase InvalidAsynchronousStateException se encuentra en el ensamblado System.ComponentModel.TypeConverter.

A partir de .NET Core 3.0, se encuentra en el ensamblado System.ComponentModel.Primitives.

Versión introducida

3.0

Este cambio solo afecta a las aplicaciones que usan la reflexión para cargar InvalidAsynchronousStateException mediante la llamada a un método como Assembly.GetType, o una sobrecarga de Activator.CreateInstance que supone que el tipo está en un ensamblado determinado. En ese caso, actualice el ensamblado al que se hace referencia en la llamada de método para reflejar la nueva ubicación del ensamblado del tipo.

Categoría

Bibliotecas de Core .NET

API afectadas

Ninguno.

Al reemplazar las secuencias de bytes UTF-8 con formato incorrecto se siguen las instrucciones de Unicode

Cuando la clase UTF8Encoding encuentra una secuencia de bytes UTF-8 con formato incorrecto durante una operación de transcodificación de byte a carácter, reemplaza esa secuencia por un carácter "�" (CARÁCTER DE REEMPLAZO DE U+FFFD) en la cadena de salida. .NET Core 3.0 se diferencia de las versiones anteriores de .NET Core y de .NET Framework en que sigue los procedimientos recomendados de Unicode para realizar este reemplazo durante la operación de transcodificación.

Esto forma parte de un trabajo mayor para mejorar el control de UTF-8 en .NET, que los nuevos tipos System.Text.Unicode.Utf8 y System.Text.Rune incluyen. Se asignó una mecánica de control de errores mejorada al tipo UTF8Encoding para que genere una salida coherente con los tipos recién incorporados.

Descripción del cambio

A partir de .NET Core 3.0, al transcodificar bytes en caracteres, la clase UTF8Encoding realiza la sustitución de caracteres en función de los procedimientos recomendados de Unicode. El mecanismo de sustitución que se usa se describe en The Unicode Standard, Version 12.0, Sec. 3.9 (PDF) en el apartado titulado U+FFFD Substitution of Maximal Subparts.

Este comportamiento solo se aplica cuando la secuencia de bytes de entrada contiene datos UTF-8 con formato incorrecto. Además, si la instancia de UTF8Encoding se ha construido con throwOnInvalidBytes: true, la instancia de UTF8Encodingcontinuará produciéndose en una entrada no válida en lugar de realizar el reemplazo de U+FFFD. Para obtener más información sobre el constructor UTF8Encoding, vea UTF8Encoding(Boolean, Boolean).

En la siguiente tabla se muestra el impacto de este cambio con una entrada de 3 bytes no válida:

Entrada de 3 bytes con formato incorrecto Salida antes de .NET Core 3.0 Salida a partir de .NET Core 3.0
[ ED A0 90 ] [ FFFD FFFD ] (salida de 2 caracteres) [ FFFD FFFD FFFD ] (salida de 3 caracteres)

La salida de 3 caracteres es la preferida, según la tabla 3-9 del PDF del estándar Unicode vinculado anteriormente.

Versión introducida

3.0

No se requiere ninguna acción por parte del desarrollador.

Categoría

Bibliotecas de Core .NET

API afectadas

Se ha movido TypeDescriptionProviderAttribute a otro ensamblado

La clase TypeDescriptionProviderAttribute se ha movido.

Descripción del cambio

En .NET Core 2.2 y en versiones anteriores, la clase TypeDescriptionProviderAttribute se encuentra en el ensamblado System.ComponentModel.TypeConverter.

A partir de .NET Core 3.0, se encuentra en el ensamblado System.ObjectModel.

Versión introducida

3.0

Este cambio solo afecta a las aplicaciones que usan la reflexión para cargar el tipo TypeDescriptionProviderAttribute mediante la llamada a un método como Assembly.GetType, o una sobrecarga de Activator.CreateInstance que supone que el tipo está en un ensamblado determinado. En ese caso, el ensamblado al que se hace referencia en la llamada al método debe actualizarse para reflejar la nueva ubicación del ensamblado del tipo.

Categoría

Windows Forms

API afectadas

Ninguno.

ZipArchiveEntry ya no controla los archivos con tamaños de entrada incoherentes

Los archivos zip muestran tanto el tamaño comprimido como el tamaño no comprimido en el directorio central y en el encabezado local. Los propios datos de entrada también indican su tamaño. En .NET Core 2.2 y versiones anteriores, nunca se comprobó la coherencia de estos valores. A partir de .NET Core 3.0, ahora son.

Descripción del cambio

En .NET Core 2.2 y versiones anteriores, ZipArchiveEntry.Open() funciona correctamente aunque el encabezado local no concuerde con el encabezado central del archivo zip. Los datos se descomprimen hasta que se alcanza el final del flujo comprimido, aunque su longitud supere el tamaño de archivo sin comprimir que se muestra en el directorio central/encabezado local.

A partir de .NET Core 3.0, el método ZipArchiveEntry.Open() comprueba que el encabezado local y el encabezado central coinciden en el tamaño comprimido y no comprimido de una entrada. Si no coinciden, el método produce una InvalidDataException si el encabezado local del archivo o el tamaño de la lista de descriptores de datos que no están en desacuerdo con el directorio central del archivo zip. Al leer una entrada, los datos descomprimidos se truncan hasta el tamaño de archivo sin comprimir que se muestra en el encabezado.

Este cambio se realizó para asegurarse de que un ZipArchiveEntryrepresenta correctamente el tamaño de sus datos y que solo se lee esa cantidad de datos.

Versión introducida

3.0

Vuelva a empaquetar los archivos ZIP que presentan estos problemas.

Categoría

Bibliotecas de Core .NET

API afectadas

FieldInfo.SetValue produce una excepción en los campos estáticos de solo inicialización

A partir de .NET Core 3.0, se produce una excepción si intenta establecer un valor en un campo InitOnly estático al llamar a System.Reflection.FieldInfo.SetValue.

Descripción del cambio

En .NET Framework y en versiones de .NET Core anteriores a la 3.0, podía establecer el valor de un campo estático constante una vez inicializado (readonly en C#) mediante una llamada a System.Reflection.FieldInfo.SetValue. Con todo, al establecer este tipo de campo de esta manera, se producía un comportamiento imprevisible en función de la plataforma de destino y la configuración de optimización.

En .NET Core 3.0 y versiones posteriores, al llamar a SetValue en un campo InitOnly estático, se produce una excepción System.FieldAccessException.

Sugerencia

Un campo InitOnly es uno que solo se puede establecer en el momento en que se declara o en el constructor de la clase contenedora. En otras palabras, es constante después de inicializarse.

Versión introducida

3.0

Inicialice los campos InitOnly estáticos en un constructor estático. Esto se aplica a los tipos dinámicos y no dinámicos.

Como alternativa, puede quitar el atributo FieldAttributes.InitOnly del campo y después llamar a FieldInfo.SetValue.

Categoría

Bibliotecas de Core .NET

API afectadas

El paso de GroupCollection a métodos de extensión que toman IEnumerable<T> requiere desambiguación

Al llamar a un método de extensión que toma IEnumerable<T> en un elemento GroupCollection, se debe eliminar la ambigüedad del tipo mediante una conversión.

Descripción del cambio

A partir de .NET Core 3.0, System.Text.RegularExpressions.GroupCollection implementa IEnumerable<KeyValuePair<String,Group>>, además de los otros tipos que implementa, incluido IEnumerable<Group>. Esto produce ambigüedad al llamar a un método de extensión que toma un elemento IEnumerable<T>. Si llama a un método de extensión como este en una instancia de GroupCollection, por ejemplo, Enumerable.Count, verá el error del compilador siguiente:

CS1061: "GroupCollection" no contiene una definición para "Count" ni se encuentra ningún método de extensión accesible "Count" que acepte un primer argumento del tipo "GroupCollection" (¿falta una directiva de uso o una referencia de ensamblado?) .

En versiones anteriores de .NET, no había ambigüedad ni ningún error del compilador.

Versión introducida

3.0

Motivo del cambio

Se trató de un cambio importante involuntario. Dado que no es algo nuevo de ahora, no tenemos previsto revertirlo. Además, un cambio de este tipo sería importante en sí mismo.

En el caso de instancias de GroupCollection, elimine la ambigüedad de las llamadas a métodos de extensión que aceptan un elemento IEnumerable<T> con una conversión.

// Without a cast - causes CS1061.
match.Groups.Count(_ => true)

// With a disambiguating cast.
((IEnumerable<Group>)m.Groups).Count(_ => true);

Categoría

Bibliotecas de Core .NET

API afectadas

Los métodos de extensión que aceptan un elemento IEnumerable<T> se ven afectados. Por ejemplo:

Criptografía

Ya no se admite la sintaxis "BEGIN TRUSTED CERTIFICATE" en certificados raíz de Linux

Los certificados raíz de Linux y otros sistemas similares a Unix (a excepción de macOS) se pueden presentar de dos formas: el encabezado PEM BEGIN CERTIFICATE estándar y el encabezado PEM BEGIN TRUSTED CERTIFICATE específico de OpenSSL. La última sintaxis permite una configuración adicional que ha provocado problemas de compatibilidad con la clase System.Security.Cryptography.X509Certificates.X509Chain de .NET Core. El motor de cadena ya no carga el contenido del certificado raíz BEGIN TRUSTED CERTIFICATE a partir de .NET Core 3.0.

Descripción del cambio

Anteriormente, las sintaxis BEGIN CERTIFICATE y BEGIN TRUSTED CERTIFICATE se usaban para rellenar la lista de confianza raíz. Si se ha usado la sintaxis BEGIN TRUSTED CERTIFICATE y se han especificado opciones adicionales en el archivo, es posible que X509Chain haya informado de que la confianza de cadena no se permite explícitamente (X509ChainStatusFlags.ExplicitDistrust). Con todo, si el certificado también se había especificado con la sintaxis BEGIN CERTIFICATE en un archivo cargado anteriormente, se permitía la confianza de cadena.

A partir de .NET Core 3.0, ya no se lee el contenido de BEGIN TRUSTED CERTIFICATE. Si el certificado no se especifica también mediante una sintaxis BEGIN CERTIFICATE estándar, X509Chain informa de que la raíz no es de confianza (X509ChainStatusFlags.UntrustedRoot).

Versión introducida

3.0

La mayoría de las aplicaciones no se ven afectadas por este cambio, pero las aplicaciones que no pueden ver ambos orígenes del certificado raíz por problemas de permisos pueden experimentar errores inesperados de UntrustedRoot después de actualizarse.

Muchas distribuciones de Linux escriben certificados raíz en dos ubicaciones: un directorio con un certificado por archivo y una concatenación de un archivo. En algunas distribuciones, el directorio con un certificado por archivo usa la sintaxis BEGIN TRUSTED CERTIFICATE mientras que la concatenación de archivos usa la sintaxis BEGIN CERTIFICATE estándar. Asegúrese de que los certificados raíz personalizados se agregan como BEGIN CERTIFICATE en al menos una de estas ubicaciones y que la aplicación puede leer ambas ubicaciones.

El directorio típico es /etc/ssl/certs/ y el archivo concatenado típico es /etc/ssl/cert.pem. Use el comando openssl version -d para determinar la raíz específica de la plataforma, que puede ser diferente de /etc/ssl/ . Por ejemplo, en Ubuntu 18.04, el directorio es /usr/lib/ssl/certs/ y el archivo es /usr/lib/ssl/cert.pem. A pesar de esto, /usr/lib/ssl/certs/ es un vínculo simbólico a /etc/ssl/certs/ y /usr/lib/ssl/cert.pem no existe.

$ openssl version -d
OPENSSLDIR: "/usr/lib/ssl"
$ ls -al /usr/lib/ssl
total 12
drwxr-xr-x  3 root root 4096 Dec 12 17:10 .
drwxr-xr-x 73 root root 4096 Feb 20 15:18 ..
lrwxrwxrwx  1 root root   14 Mar 27  2018 certs -> /etc/ssl/certs
drwxr-xr-x  2 root root 4096 Dec 12 17:10 misc
lrwxrwxrwx  1 root root   20 Nov 12 16:58 openssl.cnf -> /etc/ssl/openssl.cnf
lrwxrwxrwx  1 root root   16 Mar 27  2018 private -> /etc/ssl/private

Categoría

Criptografía

API afectadas

EnvelopedCms utiliza de forma predeterminada el cifrado AES-256

El algoritmo de cifrado simétrico predeterminado que usa EnvelopedCms ha cambiado de TripleDES a AES-256.

Descripción del cambio

En versiones anteriores, cuando se usa EnvelopedCms para cifrar datos sin especificar un algoritmo de cifrado simétrico a través de una sobrecarga de constructor, los datos se cifran con el algoritmo TripleDES/3DES/3DEA/DES3-EDE.

A partir de .NET Core 3.0 (a través de la versión 4.6.0 del paquete NuGet System.Security.Cryptography.Pkcs), el algoritmo predeterminado se ha cambiado a AES-256 para la modernización de algoritmos y para mejorar la seguridad de opciones predeterminadas. Si el certificado del destinatario de un mensaje tiene una clave pública Diffie-Hellman (no de cliente de empresa), es posible que se produzca un error CryptographicException en la operación de cifrado debido a limitaciones de la plataforma subyacente.

En el siguiente código de ejemplo, los datos se cifran con TripleDES si se ejecutan en .NET Core 2.2 o anterior. Si se ejecutan en .NET Core 3.0 o posterior, se cifran con AES-256.

EnvelopedCms cms = new EnvelopedCms(content);
cms.Encrypt(recipient);
return cms.Encode();

Versión introducida

3.0

Si el cambio le afecta negativamente, puede restaurar el cifrado TripleDES especificando explícitamente el identificador del algoritmo de cifrado en un constructor de EnvelopedCms que incluya un parámetro del tipo AlgorithmIdentifier, por ejemplo:

Oid tripleDesOid = new Oid("1.2.840.113549.3.7", null);
AlgorithmIdentifier tripleDesIdentifier = new AlgorithmIdentifier(tripleDesOid);
EnvelopedCms cms = new EnvelopedCms(content, tripleDesIdentifier);

cms.Encrypt(recipient);
return cms.Encode();

Categoría

Criptografía

API afectadas

Ha aumentado el tamaño mínimo de la generación de claves RSAOpenSsl

El tamaño mínimo para generar nuevas claves RSA en Linux ha aumentado de 384 bits a 512 bits.

Descripción del cambio

A partir de .NET Core 3.0, el tamaño mínimo de clave permitido que notifica la propiedad LegalKeySizes en instancias de RSA desde RSA.Create, RSAOpenSsl y RSACryptoServiceProvider en Linux ha aumentado de 384 a 512.

Por consiguiente, .NET Core 2.2 y versiones anteriores, una llamada de método como RSA.Create(384) se realiza correctamente. En .NET Core 3.0 y versiones posteriores, la llamada de método RSA.Create(384) produce una excepción que indica que el tamaño es demasiado pequeño.

Este cambio se realizó porque OpenSSL, que realiza las operaciones criptográficas en Linux, ha aumentado su mínimo entre las versiones 1.0.2 y 1.1.0. .NET Core 3.0 prefiere OpenSSL 1.1. x a 1.0. x, y la versión mínima notificada se elevó para reflejar esta nueva limitación de dependencia más alta.

Versión introducida

3.0

Si llama a cualquiera de las API afectadas, asegúrese de que el tamaño de las claves generadas no sea inferior al mínimo del proveedor.

Nota:

El RSA de 384 bits ya se considera inseguro (al igual que el RSA de 512 bits). Las recomendaciones modernas, como NIST Special Publication 800-57 Part 1 Revision 4, sugieren 2048 bits como tamaño mínimo para las claves recién generadas.

Categoría

Criptografía

API afectadas

.NET Core 3.0 prefiere OpenSSL 1.1.x a OpenSSL 1.0.x

.NET Core para Linux, que funciona en varias distribuciones de Linux, puede admitir OpenSSL 1.0.x y OpenSSL 1.1.x. .NET Core 2.1 y .NET Core 2.2 buscan 1.0.x primero y luego recurren a 1.1.x; .NET Core 3.0 busca 1.1.x primero. Este cambio se realizó para agregar compatibilidad con nuevos estándares criptográficos.

Este cambio puede afectar a las bibliotecas o aplicaciones que llevan a cabo la interoperabilidad de la plataforma con los tipos de interoperabilidad específicos de OpenSSL en .NET Core.

Descripción del cambio

En .NET Core 2.2 y versiones anteriores, el runtime prefiere cargar OpenSSL 1.0.x a 1.1.x. Esto significa que los tipos IntPtr y SafeHandle para la interoperabilidad con OpenSSL se usan, por orden de preferencia, con libcrypto.so.1.0.0 / libcrypto.so.1.0 / libcrypto.so.10.

A partir de .NET Core 3.0, el runtime prefiere cargar OpenSSL 1.1.x a OpenSSL 1.0.x, por lo que los tipos IntPtr y SafeHandle para la interoperabilidad con OpenSSL se usan, por orden de preferencia, con libcrypto.so.1.1 / libcrypto.so.11 / libcrypto.so.1.1.0 / libcrypto.so.1.1.1. Por consiguiente, las bibliotecas y aplicaciones que interactúan directamente con OpenSSL pueden tener punteros incompatibles con los valores expuestos en .NET Core cuando se actualiza desde .NET Core 2.1 o.NET Core 2.2.

Versión introducida

3.0

Las bibliotecas y aplicaciones que realizan operaciones directas con OpenSSL deben tener cuidado de asegurarse de que usan la misma versión de OpenSSL que el runtime de .NET Core.

Todas las bibliotecas o aplicaciones que usan los valores IntPtr o SafeHandle de los tipos criptográficos de .NET Core directamente con OpenSSL deben comparar la versión de la biblioteca que usan con la nueva propiedad SafeEvpPKeyHandle.OpenSslVersion para asegurarse de que los punteros son compatible.

Categoría

Criptografía

API afectadas

Transformación del bloque final solo durante el proceso de escritura mediante CryptoStream.Dispose

El método CryptoStream.Dispose, que se usa para finalizar operaciones CryptoStream, ya no intenta transformar el bloque final durante la lectura.

Descripción del cambio

En versiones anteriores de .NET, si un usuario realizaba una lectura incompleta al usar CryptoStream en el modo Read, el método Dispose podía producir una excepción (por ejemplo, al usar AES con espaciado interno). Se producía la excepción porque se intentaba transformar el bloque final, pero los datos estaban incompletos.

En .NET Core 3.0 y versiones posteriores, Dispose ya no intenta transformar el bloque final durante la lectura, lo que permite hacer lecturas incompletas.

Motivo del cambio

Este cambio permite las lecturas incompletas de la secuencia de cifrado cuando se cancela una operación de red, sin necesidad de capturar una excepción.

Versión introducida

3.0

La mayoría de las aplicaciones no se verán afectadas por este cambio.

Si su aplicación detectaba anteriormente una excepción en caso de una lectura incompleta, puede eliminar ese bloque catch. Si su aplicación usaba la transformación del bloque final en operaciones hash, puede que tenga que asegurarse de que se lee toda la secuencia antes de eliminar el bloque.

Categoría

Criptografía

API afectadas

Entity Framework Core

Cambios importantes de Entity Framework Core

Globalización

La configuración regional de “C” se asigna a la configuración regional invariable

.NET Core 2.2 y las versiones anteriores dependen del comportamiento predeterminado de ICU, el cual asigna la configuración regional de “C” a la configuración regional en_US_POSIX. La configuración regional en_US_POSIX tiene un comportamiento de intercalación no deseado, porque no admite comparaciones de cadenas que no distinguen mayúsculas de minúsculas. Algunas distribuciones de Linux establecían la configuración regional de “C” como la configuración regional predeterminada, por lo que los usuarios experimentaban un comportamiento inesperado.

Descripción del cambio

A partir de .NET Core 3.0, la asignación de la configuración regional de “C” ha cambiado para usar la configuración regional invariable en lugar de en_US_POSIX. La configuración regional de “C” con la asignación invariable también se aplica a Windows para mantener la coherencia.

La asignación de “C” a la referencia cultural en_US_POSIX causaba confusión entre los clientes porque en_US_POSIX no admite operaciones de ordenación y búsqueda de cadenas que no distinguen mayúsculas de minúsculas. Dado que la configuración regional de “C” se usa como configuración regional predeterminada en algunas de las distribuciones de Linux, los clientes experimentaron este comportamiento no deseado en estos sistemas operativos.

Versión introducida

3.0

Nada más aparte de conocer este cambio. Este cambio solo afecta a las aplicaciones que usan la asignación de configuración regional de “C”.

Categoría

Globalización

API afectadas

Este cambio afecta a todas las API de intercalación y de referencia cultural.

MSBuild

Cambio de nombre de archivo de manifiesto del recurso

A partir de .NET Core 3.0, en el caso predeterminado, MSBuild genera un nombre de archivo de manifiesto diferente para los archivos de recursos.

Versión introducida

3.0

Descripción del cambio

Antes de .NET Core 3.0, si no se especificaban los metadatos LogicalName, ManifestResourceName o DependentUpon para un elemento de EmbeddedResource del archivo del proyecto, MSBuild generaba un nombre de archivo de manifiesto con el patrón <RootNamespace>.<ResourceFilePathFromProjectRoot>.resources. Si RootNamespace no está definido en el archivo del proyecto, se toma como valor predeterminado el nombre del proyecto. Por ejemplo, el nombre de manifiesto generado para un archivo de recursos denominado Form1.resx en el directorio raíz del proyecto era suproject.Form1.Resources.

A partir de .NET Core 3.0, si un archivo de recursos está ubicado conjuntamente con un archivo de código fuente del mismo nombre (por ejemplo, Form1.resx y Form1.cs), MSBuild usa la información de tipo del archivo de código fuente para generar el nombre del archivo de manifiesto con el patrón <Namespace>.<ClassName>.resources. El espacio de nombres y el nombre de clase se extraen del primer tipo del archivo de código fuente ubicado conjuntamente. Por ejemplo, el nombre de manifiesto generado para un archivo de recursos denominado Form1.resx que se ubica conjuntamente con un archivo de código fuente denominado Form1.cs es myNameSpace.Form1.Resources. Lo más importante que hay que tener en cuenta es que la primera parte del nombre de archivo es diferente en versiones anteriores de .NET Core (myNameSpace en lugar de MyProject).

Nota

Si tiene los metadatos LogicalName, ManifestResourceName o DependentUpon especificados en un elemento EmbeddedResource del archivo del proyecto, este cambio no afecta a ese archivo de recursos.

Este cambio importante se presentó con la incorporación de la propiedad EmbeddedResourceUseDependentUponConvention a los proyectos de .NET Core. De forma predeterminada, los archivos de recursos no se enumeran explícitamente en un archivo de proyecto de .NET Core, por lo que no tienen metadatos DependentUpon para especificar cómo nombrar el archivo .resources generado. Cuando EmbeddedResourceUseDependentUponConvention se establece en true, que es el valor predeterminado, MSBuild busca un archivo de código fuente ubicado conjuntamente y extrae un espacio de nombres y un nombre de clase de ese archivo. Si establece EmbeddedResourceUseDependentUponConvention en false, MSBuild genera el nombre del manifiesto según el comportamiento anterior, que combina RootNamespace y la ruta de acceso relativa del archivo.

En la mayoría de los casos, no se requiere ninguna acción por parte del desarrollador y la aplicación seguirá funcionando. Sin embargo, si este cambio invalida la aplicación, puede:

  • Cambiar el código para que espere el nuevo nombre de manifiesto.

  • Rechazar la nueva convención de nomenclatura mediante el establecimiento de EmbeddedResourceUseDependentUponConvention en false en el archivo del proyecto.

    <PropertyGroup>
  <EmbeddedResourceUseDependentUponConvention>false</EmbeddedResourceUseDependentUponConvention>
</PropertyGroup>

Categoría

MSBuild

API afectadas

N/D

Redes

El valor predeterminado de HttpRequestMessage.Version ha cambiado a 1.1

El valor predeterminado de la propiedad System.Net.Http.HttpRequestMessage.Version ha cambiado de 2.0 a 1.1.

Versión introducida

3.0

Descripción del cambio

En las versiones 1.0 a 2.0 de .NET Core, el valor predeterminado de la propiedad System.Net.Http.HttpRequestMessage.Version es 1.1. A partir de la versión 2.1 de .NET Core, se ha cambiado a 2.1.

A partir de la versión 3.0 de .NET Core, el número de versión predeterminado devuelto por la propiedad System.Net.Http.HttpRequestMessage.Version es, una vez más, 1.1.

Actualice el código si depende de que la propiedad System.Net.Http.HttpRequestMessage.Version devuelva un valor predeterminado de 2.0.

Categoría

Redes

API afectadas

Consulte también