Compartir a través de

Novedades de .NET Framework

  • Artículo

Nota

.NET Framework se ofrece independientemente de las actualizaciones de Windows con correcciones de errores de seguridad y confiabilidad. En general, las actualizaciones de seguridad se publican trimestralmente. .NET Framework seguirá estando incluido con Windows, sin planes para quitarlo. No es necesario migrar las aplicaciones de .NET Framework, pero para el nuevo desarrollo, use .NET 8 o posterior.

En este artículo se resumen las nuevas características y mejoras clave de las siguientes versiones de .NET Framework:

Este artículo no proporciona información completa sobre cada nueva característica y está sujeta a cambios. Para obtener información general sobre .NET Framework, consulte Introducción. Para las plataformas compatibles, consulte Requisitos del sistema. Para obtener vínculos de descarga e instrucciones de instalación, consulte Guía de instalación.

Nota

El equipo de .NET Framework también publica características fuera de banda, mediante NuGet, para expandir la compatibilidad con la plataforma e introducir nuevas funcionalidades, como colecciones inmutables y tipos de vector habilitados para SIMD. Para obtener más información, vea Bibliotecas de clases y API adicionales y .NET Framework y versiones fuera de banda. Vea una lista completa de paquetes NuGet para .NET Framework.

Introducción a .NET Framework 4.8.1

.NET Framework 4.8.1 se basa en versiones anteriores de .NET Framework 4.x mediante la adición de muchas correcciones nuevas y varias características nuevas, mientras permanece un producto muy estable.

Descarga e instalación de .NET Framework 4.8.1

Puede descargar .NET Framework 4.8.1 desde las siguientes ubicaciones:

.NET Framework 4.8 se puede instalar en Windows 11, Windows 10 versión 21H2, Windows 10 versión 21H1, Windows 10 versión 20H2 y las plataformas de servidor correspondientes a partir de Windows Server 2022. Puede instalar .NET Framework 4.8.1 mediante el instalador web o el instalador sin conexión. La manera recomendada para la mayoría de los usuarios es usar el instalador web.

Puede elegir .NET Framework 4.8.1 como destino en Visual Studio 2022 17.3 o una versión posterior con la instalación del Paquete de desarrollador de .NET Framework 4.8.1.

Novedades de .NET Framework 4.8.1

.NET Framework 4.8.1 presenta nuevas características en las siguientes áreas:

Accesibilidad mejorada, que permite a una aplicación proporcionar una experiencia adecuada para los usuarios de tecnología de asistencia, es un enfoque importante de .NET Framework 4.8.1. Para obtener información sobre las mejoras de accesibilidad en .NET Framework 4.8.1, consulte Novedades de accesibilidad en .NET Framework.

.NET Framework 4.8.1 agrega compatibilidad nativa con Arm64 a la familia de .NET Framework. Por lo tanto, las inversiones en el amplio ecosistema de aplicaciones y bibliotecas de .NET Framework ahora pueden aprovechar las ventajas de ejecutar cargas de trabajo de forma nativa en Arm64, es decir, un mejor rendimiento en comparación con la ejecución de código x64 emulado en Arm64.

Microsoft se ha comprometido a proporcionar productos y plataformas accesibles para todos los usuarios. .NET Framework 4.8.1 ofrece dos plataformas de desarrollo de interfaz de usuario de Windows, que proporcionan a los desarrolladores la compatibilidad necesaria para crear aplicaciones accesibles. En las últimas versiones, Windows Forms y WPF han agregado nuevas características y han corregido numerosos problemas de confiabilidad relacionados con la accesibilidad. Para obtener más información sobre los detalles de lo que se ha corregido o agregado en cada versión, visite Novedades de accesibilidad en .NET Framework.

En esta versión, tanto Windows Forms como WPF han realizado mejoras en el control de la información sobre herramientas para que sea más accesible. En ambos casos, la información sobre herramientas ahora cumple las directrices establecidas en la guía WCAG2.1 sobre contenido al mantener el puntero o aplicarle el foco. Los requisitos para obtener información sobre herramientas son:

  • La información sobre herramientas debe mostrarse al mantener el puntero del ratón o al navegar con el teclado hasta el control.
  • La información sobre herramientas debe poder descartarse. Es decir, un sencillo comando de teclado, como Esc, debe descartar la información sobre herramientas.
  • La información sobre herramientas debe admitir que se mantenga el puntero del ratón. Los usuarios deben poder colocar el cursor del ratón encima de la información sobre herramientas. Esto permite escenarios como el uso de la lupa para poder leer la información sobre herramientas de los usuarios con visión reducida.
  • La información sobre herramientas debe ser persistente. La información sobre herramientas no debe desaparecer automáticamente después de que haya transcurrido una determinada cantidad de tiempo. Más bien, el usuario debe descartar la información sobre herramientas al mover el ratón a otro control o con un comando de teclado.

En Windows Forms, esta compatibilidad solo está disponible en sistemas operativos Windows 11 o posteriores. Windows Forms es un contenedor administrado ligero en torno a la API de Windows y el nuevo comportamiento de la información sobre herramientas solo está disponible en Windows 11. WPF no tiene dependencias de versión del sistema operativo para sus tooltips accesibles.

WPF había implementado la mayoría de los requisitos para una información sobre herramientas conforme con WCAG2.1 en .NET Framework 4.8. En esta versión, WPF mejoró la experiencia asegurándose de que un tooltip en la ventana actual se pueda descartar fácilmente mediante la tecla Esc, la tecla Ctrl (por sí solo) o mediante la combinación Ctrl+Shift+F10. El ámbito de la clave de escape se redujo en esta versión para aplicar solo a la ventana actual. Antes se aplicaba a cualquier información sobre herramientas que hubiera abierta en la aplicación.

Windows Forms fue la primera pila de interfaz de usuario de Windows creada para .NET Framework. Como tal, se creó originalmente para usar la tecnología de accesibilidad heredada, que no cumple los requisitos de accesibilidad actuales. En esta versión, Windows Forms ha solucionado varios problemas. Para obtener una lista completa de los cambios relacionados con la accesibilidad, visite Novedades de accesibilidad en .NET Framework.

Los aspectos destacados de las mejoras de Windows Forms en .NET Framework 4.8.1 son:

  • Compatibilidad con patrones de texto: Formularios Windows Forms han agregado compatibilidad con el patrón de texto UIA. Este patrón permite que la tecnología de asistencia recorra el contenido de un TextBox o un control similar basado en texto, letra a letra. Permite seleccionar y modificar texto dentro del control, así como insertar nuevo texto en el cursor. Windows Forms agregó esta compatibilidad con textBox, celdas DataGridView, controles ComboBox, etc.

  • Solucionar problemas de contraste: en varios controles, Windows Forms ha cambiado la relación de contraste de rectángulos de selección para que sea más oscuro y más visible.

  • Se han corregido varios problemas de DataGridView:

    • Los nombres de la barra de desplazamiento se han actualizado para ser coherentes.
    • El narrador ahora puede centrarse en celdas de DataGridView vacías.
    • Los desarrolladores pueden establecer la propiedad de tipo de control localizado para las celdas Custom DataGridView.
    • El color del vínculo para las celdas DataGridViewLink se ha actualizado para tener un mejor contraste con el fondo.

Introducción a .NET Framework 4.8

.NET Framework 4.8 se basa en versiones anteriores de .NET Framework 4.x mediante la adición de muchas correcciones nuevas y varias características nuevas mientras permanece un producto muy estable.

Descarga e instalación de .NET Framework 4.8

Puede descargar .NET Framework 4.8 desde las siguientes ubicaciones:

.NET Framework 4.8 se puede instalar en Windows 10, Windows 8.1, Windows 7 SP1 y las plataformas de servidor correspondientes a partir de Windows Server 2008 R2 SP1. Puede instalar .NET Framework 4.8 mediante el instalador web o el instalador sin conexión. La manera recomendada para la mayoría de los usuarios es usar el instalador web.

Puede usar como destino .NET Framework 4.8 en Visual Studio 2012 o una versión posterior mediante la instalación del Paquete de desarrollador de .NET Framework 4.8.

Novedades de .NET Framework 4.8

.NET Framework 4.8 presenta nuevas características en las siguientes áreas:

La accesibilidad mejorada, que permite a una aplicación proporcionar una experiencia adecuada para los usuarios de tecnología de asistencia, sigue siendo un enfoque importante de .NET Framework 4.8. Para obtener información sobre las mejoras de accesibilidad en .NET Framework 4.8, consulte Novedades de accesibilidad en .NET Framework.

Clases base

Impacto de FIPS reducido sobre la criptografía. En versiones anteriores de .NET Framework, las clases de proveedor criptográfico administrado, como SHA256Managed inician un CryptographicException cuando las bibliotecas criptográficas del sistema están configuradas en "modo FIPS". Estas excepciones se producen porque las versiones administradas de las clases de proveedor criptográfico, a diferencia de las bibliotecas criptográficas del sistema, no se han sometido a la certificación FIPS (Federal Information Processing Standards) 140-2. Dado que pocos desarrolladores tienen sus máquinas de desarrollo en modo FIPS, las excepciones se producen normalmente en los sistemas de producción.

De forma predeterminada, en las aplicaciones destinadas a .NET Framework 4.8, las siguientes clases de criptografía administradas ya no inician una CryptographicException en este caso:

En su lugar, estas clases redirigen las operaciones criptográficas a una biblioteca de criptografía del sistema. Este cambio elimina eficazmente una diferencia potencialmente confusa entre entornos de desarrollador y entornos de producción y hace que los componentes nativos y los componentes administrados funcionen con la misma directiva criptográfica. Las aplicaciones que dependen de estas excepciones pueden restaurar el comportamiento anterior estableciendo el modificador AppContext Switch.System.Security.Cryptography.UseLegacyFipsThrow en true. Para obtener más información, vea Las clases de criptografía administradas no lanzan una CryptographyException en el modo FIPS.

Uso de la versión actualizada de ZLib

A partir de .NET Framework 4.5, el ensamblado de clrcompression.dll usa ZLib, una biblioteca externa nativa para la compresión de datos, con el fin de proporcionar una implementación para el algoritmo de desflado. La versión de .NET Framework 4.8 de clrcompression.dll se actualiza para usar la versión 1.2.11 de ZLib, que incluye varias mejoras y correcciones clave.

Windows Communication Foundation (WCF)

Introducción de ServiceHealthBehavior

Los puntos de conexión de mantenimiento se usan ampliamente en las herramientas de orquestación para administrar servicios en función de su estado de mantenimiento. Las comprobaciones de estado también se pueden usar mediante herramientas de supervisión para realizar un seguimiento y proporcionar notificaciones sobre la disponibilidad y el rendimiento de un servicio.

ServiceHealthBehavior es un comportamiento del servicio WCF que amplía IServiceBehavior. Cuando un comportamiento de servicio se agrega a la colección ServiceDescription.Behaviors, hace lo siguiente:

  • Devuelve el estado de mantenimiento del servicio con códigos de respuesta HTTP. Puede especificar en una cadena de consulta el código de estado HTTP para una solicitud de sondeo de estado HTTP/GET.

  • Publica información sobre el estado del servicio. Los detalles específicos del servicio, incluidos el estado del servicio, los recuentos de limitación y la capacidad se pueden mostrar mediante una solicitud HTTP/GET con la cadena de consulta ?health. La facilidad de acceso a esta información es importante al solucionar problemas de un servicio WCF de comportamiento erróneo.

Hay dos maneras de exponer el punto de conexión de mantenimiento y publicar información de mantenimiento del servicio WCF:

  • A través del código. Por ejemplo:

    ServiceHost host = new ServiceHost(typeof(Service1),
                   new Uri("http://contoso:81/Service1"));
ServiceHealthBehavior healthBehavior =
    host.Description.Behaviors.Find<ServiceHealthBehavior>();
healthBehavior ??= new ServiceHealthBehavior();
host.Description.Behaviors.Add(healthBehavior);

    Dim host As New ServiceHost(GetType(Service1),
            New Uri("http://contoso:81/Service1"))
Dim healthBehavior As ServiceHealthBehavior =
   host.Description.Behaviors.Find(Of ServiceHealthBehavior)()
If healthBehavior Is Nothing Then
   healthBehavior = New ServiceHealthBehavior()
End If
host.Description.Behaviors.Add(healthBehavior)

  • Mediante un archivo de configuración. Por ejemplo:

    <behaviors>
  <serviceBehaviors>
    <behavior name="DefaultBehavior">
      <serviceHealth httpsGetEnabled="true"/>
    </behavior>
  </serviceBehaviors>
</behaviors>

El estado de mantenimiento de un servicio se puede consultar mediante parámetros de consulta como OnServiceFailure, OnDispatcherFailure, OnListenerFailure, OnThrottlePercentExceeded) y se puede especificar un código de respuesta HTTP para cada parámetro de consulta. Si se omite el código de respuesta HTTP para un parámetro de consulta, se usa de forma predeterminada un código de respuesta HTTP 503. Por ejemplo:

Parámetros y ejemplos de consulta:

  • OnDispatcherFailure: https://contoso:81/Service1?health&OnDispatcherFailure=455

    se devuelve un código de estado de respuesta HTTP 455 cuando el estado de cualquier distribuidor de canal es mayor que CommunicationState.Opened.

  • OnListenerFailure: https://contoso:81/Service1?health&OnListenerFailure=465

    se devuelve un código de estado de respuesta HTTP 465 cuando el estado de cualquiera de las escuchas de canales es mayor que CommunicationState.Opened.

  • OnThrottlePercentExceeded: https://contoso:81/Service1?health&OnThrottlePercentExceeded= 70:350,95:500

    Especifica el porcentaje {1 – 100} que desencadena la respuesta y su código de respuesta HTTP {200 – 599}. En este ejemplo:

    • Si el porcentaje es mayor que 95, se devuelve un código de respuesta HTTP de 500.

    • Si el porcentaje está entre 70 y 95, se devuelve 350.

    • En caso contrario, se devuelve 200.

El estado de mantenimiento del servicio se puede mostrar en HTML especificando una cadena de consulta como https://contoso:81/Service1?health o en XML especificando una cadena de consulta como https://contoso:81/Service1?health&Xml. Una cadena de consulta como https://contoso:81/Service1?health&NoContent devuelve una página HTML vacía.

Windows Presentation Foundation (WPF)

Altas mejoras de PPP

En .NET Framework 4.8, WPF proporciona compatibilidad con el reconocimiento de PPP por Monitor V2 y escala de PPP en modo mixto. Consulte Desarrollo de Aplicaciones de Escritorio de Alta DPI en Windows para obtener información adicional sobre el desarrollo de alta DPI.

.NET Framework 4.8 mejora la compatibilidad con HWND hospedados y la interoperabilidad de Windows Forms en aplicaciones WPF High-DPI en plataformas que admiten el escalado de DPI Mixed-Mode (desde la actualización de Windows 10 de abril de 2018). Cuando se crean HWND hospedados o controles de Windows Forms como ventanas con escala PPP en modo mixto mediante la llamada a SetThreadDpiHostingBehavior y SetThreadDpiAwarenessContext, se pueden hospedar en una aplicación WPF por Monitor V2 y ajustar su tamaño y escalarse correctamente. Este contenido hospedado no se representa en el valor de PPP nativo, sino que el sistema operativo escala el contenido hospedado al tamaño adecuado. La compatibilidad con el modo de reconocimiento de PPP por Monitor v2 también permite hospedar los controles de WPF (es decir, convertir en elementos primarios) en una ventana nativa de una aplicación de PPP alto.

Para permitir la compatibilidad con la escalabilidad de alto PPP en modo mixto, puede establecer los siguientes modificadores AppContext en el archivo de configuración de la aplicación:

<runtime>
   <AppContextSwitchOverrides value = "Switch.System.Windows.DoNotScaleForDpiChanges=false; Switch.System.Windows.DoNotUsePresentationDpiCapabilityTier2OrGreater=false"/>
</runtime>

Common Language Runtime

El entorno de ejecución de .NET Framework 4.8 incluye los siguientes cambios y mejoras:

Mejoras en el compilador JIT. El compilador Just-In-Time (JIT) de .NET Framework 4.8 se basa en el compilador JIT de .NET Core 2.1. Muchas de las optimizaciones y todas las correcciones de errores realizadas en el compilador JIT de .NET Core 2.1 se incluyen en el compilador JIT de .NET Framework 4.8.

Mejoras de NGEN. El entorno de ejecución ha mejorado la administración de memoria para las imágenes del Generador de imágenes nativo (NGEN) de forma que los datos asignados a partir de imágenes NGEN no son residentes en memoria. Esto reduce el área expuesta disponible para los ataques que intentan ejecutar código arbitrario modificando la memoria que se ejecutará.

Examen de todos los ensamblados con antimalware. En versiones anteriores de .NET Framework, el entorno de ejecución examina todos los ensamblados cargados desde el disco mediante Windows Defender o software antimalware de terceros. Sin embargo, los ensamblados cargados desde otros orígenes, como por el método Assembly.Load(Byte[]), no se examinan y pueden contener malware no detectado. A partir de .NET Framework 4.8 que se ejecuta en Windows 10, el entorno de ejecución desencadena un examen mediante soluciones antimalware que implementan la Interfaz de detección de antimalware (AMSI).

Novedades de .NET Framework 4.7.2

.NET Framework 4.7.2 incluye nuevas características en las siguientes áreas:

Un enfoque continuo en .NET Framework 4.7.2 es una accesibilidad mejorada, lo que permite a una aplicación proporcionar una experiencia adecuada para los usuarios de tecnología de asistencia. Para obtener información sobre las mejoras de accesibilidad en .NET Framework 4.7.2, consulte Novedades de accesibilidad en .NET Framework.

Clases base

.NET Framework 4.7.2 incluye un gran número de mejoras criptográficas, una mejor compatibilidad de descompresión con archivos ZIP y API de recopilación adicionales.

Nuevas sobrecargas de RSA.Create y DSA.Create

Los métodos DSA.Create(DSAParameters) y RSA.Create(RSAParameters) permiten proporcionar parámetros clave al crear instancias de una nueva clave de DSA o RSA. Permiten reemplazar código como el siguiente:

// Before .NET Framework 4.7.2
using (RSA rsa = RSA.Create())
{
   rsa.ImportParameters(rsaParameters);
   // Other code to execute using the RSA instance.
}

' Before .NET Framework 4.7.2
Using rsa = RSA.Create()
   rsa.ImportParameters(rsaParameters)
   ' Other code to execute using the rsa instance.
End Using

con código similar al siguiente:

// Starting with .NET Framework 4.7.2
using (RSA rsa = RSA.Create(rsaParameters))
{
   // Other code to execute using the rsa instance.
}

' Starting with .NET Framework 4.7.2
Using rsa = RSA.Create(rsaParameters)
   ' Other code to execute using the rsa instance.
End Using

Los métodos DSA.Create(Int32) y RSA.Create(Int32) permiten generar nuevas claves DSA o RSA con un tamaño de clave específico. Por ejemplo:

using (DSA dsa = DSA.Create(2048))
{
   // Other code to execute using the dsa instance.
}

Using dsa = DSA.Create(2048)
   ' Other code to execute using the dsa instance.
End Using

Los constructores de Rfc2898DeriveBytes aceptan un nombre de algoritmo hash

La clase Rfc2898DeriveBytes tiene tres constructores nuevos con un parámetro HashAlgorithmName que identifica el algoritmo HMAC que se va a usar al derivar claves. En lugar de usar SHA-1, los desarrolladores deben usar un HMAC basado en SHA-2 como SHA-256, como se muestra en el ejemplo siguiente:

private static byte[] DeriveKey(string password, out int iterations, out byte[] salt,
                                out HashAlgorithmName algorithm)
{
   iterations = 100000;
   algorithm = HashAlgorithmName.SHA256;

   const int SaltSize = 32;
   const int DerivedValueSize = 32;

   using (Rfc2898DeriveBytes pbkdf2 = new Rfc2898DeriveBytes(password, SaltSize,
                                                             iterations, algorithm))
   {
      salt = pbkdf2.Salt;
      return pbkdf2.GetBytes(DerivedValueSize);
   }
}

Private Shared Function DeriveKey(password As String, ByRef iterations As Integer,
                                  ByRef salt AS Byte(), ByRef algorithm As HashAlgorithmName) As Byte()
   iterations = 100000
   algorithm = HashAlgorithmName.SHA256

   Const SaltSize As Integer = 32
   Const  DerivedValueSize As Integer = 32

   Using pbkdf2 = New Rfc2898DeriveBytes(password, SaltSize, iterations, algorithm)
      salt = pbkdf2.Salt
      Return pbkdf2.GetBytes(DerivedValueSize)
   End Using
End Function

Compatibilidad con claves efímeras

La importación de PFX puede cargar de manera opcional las claves privadas directamente desde la memoria, omitiendo la unidad de disco duro. Cuando se especifica la nueva bandera X509KeyStorageFlags.EphemeralKeySet en un constructor de X509Certificate2 o en una de las sobrecargas del método X509Certificate2.Import, las claves privadas se cargarán como claves efímeras. Esto impide que las claves estén visibles en el disco. Sin embargo:

  • Dado que las claves no se conservan en el disco, los certificados cargados con esta marca no son buenos candidatos para agregar a un X509Store.

  • Las claves que se cargan de esta manera casi siempre se cargan a través del CNG de Windows. Por tanto, los autores de la llamada deben tener acceso a la clave privada mediante la llamada a métodos de extensión, como cert.GetRSAPrivateKey(). La propiedad X509Certificate2.PrivateKey no funciona.

  • Dado que la propiedad X509Certificate2.PrivateKey heredada no funciona con certificados, los desarrolladores deben realizar pruebas rigurosas antes de cambiar a claves efímeras.

Creación mediante programación de solicitudes de firma de certificación de PKCS#10 y certificados de clave pública X.509

A partir de .NET Framework 4.7.2, las cargas de trabajo pueden generar solicitudes de firma de certificados (CSR), lo que permite almacenar provisionalmente la generación de solicitudes de certificado en herramientas existentes. Esto suele ser útil en escenarios de prueba.

Para obtener más información y ejemplos de código, vea "Creación mediante programación de solicitudes de firma de certificación PKCS#10 y certificados de clave pública X.509" en el blog de .NET.

Nuevos miembros SignerInfo

A partir de .NET Framework 4.7.2, la clase SignerInfo expone más información sobre la firma. Puede recuperar el valor de la propiedad System.Security.Cryptography.Pkcs.SignerInfo.SignatureAlgorithm para determinar el algoritmo de firma utilizado por el firmante. Para obtener una copia de la firma criptográfica de este firmante, se puede llamar a SignerInfo.GetSignature.

Mantener abierta una secuencia ajustada después de eliminar CryptoStream

A partir de .NET Framework 4.7.2, la clase CryptoStream tiene un constructor adicional que permite que Dispose no cierre el flujo envuelto. Para dejar abierta la secuencia envuelta después de desechar la instancia de CryptoStream, llame al nuevo constructor CryptoStream de la siguiente manera:

var cStream = new CryptoStream(stream, transform, mode, leaveOpen: true);

Dim cStream = New CryptoStream(stream, transform, mode, leaveOpen:=true)

Cambios de descompresión en DeflateStream

A partir de .NET Framework 4.7.2, la implementación de operaciones de descompresión en la clase DeflateStream ha cambiado para usar las API nativas de Windows de forma predeterminada. Normalmente, esto da como resultado una mejora sustancial del rendimiento.

La compatibilidad con la descompresión mediante las API de Windows está habilitada de forma predeterminada para las aplicaciones destinadas a .NET Framework 4.7.2. Las aplicaciones que tienen como destino versiones anteriores de .NET Framework, pero que se ejecutan en .NET Framework 4.7.2 pueden optar por este comportamiento agregando el siguiente modificador AppContext al archivo de configuración de la aplicación:

<AppContextSwitchOverrides value="Switch.System.IO.Compression.DoNotUseNativeZipLibraryForDecompression=false" />

API de recopilación adicionales

.NET Framework 4.7.2 agrega una serie de nuevas API a los tipos de SortedSet<T> y HashSet<T>. Estos incluyen:

La clase ConcurrentDictionary<TKey,TValue> incluye nuevas sobrecargas de los métodos AddOrUpdate y GetOrAdd para recuperar un valor del diccionario o para agregarlo si no se encuentra, y para agregar un valor al diccionario o para actualizarlo si ya existe.

public TValue AddOrUpdate<TArg>(TKey key, Func<TKey, TArg, TValue> addValueFactory, Func<TKey, TValue, TArg, TValue> updateValueFactory, TArg factoryArgument)

public TValue GetOrAdd<TArg>(TKey key, Func<TKey, TArg, TValue> valueFactory, TArg factoryArgument)

Public AddOrUpdate(Of TArg)(key As TKey, addValueFactory As Func(Of TKey, TArg, TValue), updateValueFactory As Func(Of TKey, TValue, TArg, TValue), factoryArgument As TArg) As TValue

Public GetOrAdd(Of TArg)(key As TKey, valueFactory As Func(Of TKey, TArg, TValue), factoryArgument As TArg) As TValue

ASP.NET

Compatibilidad con la inyección de dependencias en Web Forms

inserción de dependencias (DI) desacopla objetos y sus dependencias para que el código de un objeto ya no tenga que cambiarse simplemente porque ha cambiado una dependencia. Al desarrollar aplicaciones ASP.NET destinadas a .NET Framework 4.7.2, puede hacer lo siguiente:

Compatibilidad con cookies de SameSite

SameSite impide que un explorador envíe una cookie junto con una solicitud entre sitios. .NET Framework 4.7.2 agrega una propiedad HttpCookie.SameSite cuyo valor es un miembro de enumeración System.Web.SameSiteMode. Si su valor es SameSiteMode.Strict o SameSiteMode.Lax, ASP.NET agrega el atributo SameSite al encabezado set-cookie. La compatibilidad con SameSite se aplica a los objetos HttpCookie, así como a las cookies FormsAuthentication y System.Web.SessionState.

Puede establecer SameSite para un objeto HttpCookie de la siguiente manera:

var c = new HttpCookie("secureCookie", "same origin");
c.SameSite = SameSiteMode.Lax;

Dim c As New HttpCookie("secureCookie", "same origin")
c.SameSite = SameSiteMode.Lax

También puede configurar cookies de SameSite en el nivel de aplicación modificando el archivo web.config:

<system.web>
   <httpCookies sameSite="Strict" />
</system.web>

Puede agregar SameSite para FormsAuthentication y System.Web.SessionState cookies modificando el archivo de configuración web:

<system.web>
   <authentication mode="Forms">
      <forms cookieSameSite="Lax">
         <!-- ...   -->
      </forms>
   </authentication>
   <sessionState cookieSameSite="Lax"></sessionState>
</system.web>

Gestión de redes

Implementación de propiedades de HttpClientHandler

.NET Framework 4.7.1 agregó ocho propiedades a la clase System.Net.Http.HttpClientHandler. Pero dos de ellas iniciaban una excepción PlatformNotSupportedException. .NET Framework 4.7.2 ahora proporciona una implementación para estas propiedades. Las propiedades son:

SQLClient

compatibilidad con la autenticación universal de Azure Active Directory y la autenticación multifactor

Las crecientes demandas de cumplimiento y seguridad requieren que muchos clientes usen la autenticación multifactor (MFA). Además, los procedimientos recomendados actuales desalentan la inclusión de contraseñas de usuario directamente en cadenas de conexión. Para admitir estos cambios, en .NET Framework 4.7.2 se extienden las cadenas de conexión de SQLClient mediante la adición de un nuevo valor, "Active Directory Interactive", para la palabra clave "Authentication" existente para admitir MFA, y Autenticación de Azure AD. El nuevo método interactivo admite usuarios nativos y federados de Azure AD, así como usuarios invitados de Azure AD. Cuando se usa este método, se admite la autenticación de MFA impuesta por Azure AD para las bases de datos SQL. Además, el proceso de autenticación solicita una contraseña de usuario para cumplir los procedimientos recomendados de seguridad.

En versiones anteriores de .NET Framework, la conectividad de SQL solo admitía las opciones de SqlAuthenticationMethod.ActiveDirectoryPassword y SqlAuthenticationMethod.ActiveDirectoryIntegrated. Ambos forman parte del protocolo ADAL no interactivo , que no admite MFA. Con la nueva opción de SqlAuthenticationMethod.ActiveDirectoryInteractive, la conectividad de SQL admite MFA, así como los métodos de autenticación existentes (contraseña y autenticación integrada), lo que permite a los usuarios escribir contraseñas de usuario de forma interactiva sin conservar contraseñas en la cadena de conexión.

Para obtener más información y un ejemplo, vea "SQL: Compatibilidad con la autenticación universal y multifactor de Azure AD" en el blog de .NET.

Compatibilidad con Always Encrypted versión 2

NET Framework 4.7.2 agrega compatibilidad con Always Encrypted basado en enclave. La versión original de Always Encrypted es una tecnología de cifrado del lado cliente en la que las claves de cifrado nunca dejan el cliente. En Always Encrypted basado en enclave, el cliente puede enviar opcionalmente las claves de cifrado a un enclave seguro, que es una entidad computacional segura que se puede considerar parte de SQL Server, pero que el código de SQL Server no puede alterar. Para admitir Always Encrypted en enclaves, .NET Framework 4.7.2 agrega los siguientes tipos y miembros al espacio de nombres System.Data.SqlClient.

A continuación, el archivo de configuración de la aplicación especifica una implementación concreta de la clase abstracta System.Data.SqlClient.SqlColumnEncryptionEnclaveProvider que proporciona la funcionalidad para el proveedor de enclaves. Por ejemplo:

<configuration>
  <configSections>
    <section name="SqlColumnEncryptionEnclaveProviders" type="System.Data.SqlClient.SqlColumnEncryptionEnclaveProviderConfigurationSection,System.Data,Version=4.0.0.0,Culture=neutral,PublicKeyToken=b77a5c561934e089"/>
  </configSections>
  <SqlColumnEncryptionEnclaveProviders>
    <providers>
      <add name="Azure" type="Microsoft.SqlServer.Management.AlwaysEncrypted.AzureEnclaveProvider,MyApp"/>
      <add name="HGS" type="Microsoft.SqlServer.Management.AlwaysEncrypted.HGSEnclaveProvider,MyApp" />
    </providers>
  </SqlColumnEncryptionEnclaveProviders >
</configuration>

El flujo básico de Always Encrypted basada en enclave es el siguiente:

  1. El usuario crea una conexión de AlwaysEncrypted a SQL Server que admita Always Encrypted basada en enclave. El controlador se pone en contacto con el servicio de atestación para asegurarse de que se está conectando al enclave correcto.

  2. Una vez atestiguado el enclave, el controlador establece un canal seguro con el enclave seguro hospedado en SQL Server.

  3. El controlador comparte claves de cifrado autorizadas por el cliente con el enclave seguro mientras dure la conexión SQL.

Windows Presentation Foundation

Búsqueda de objetos ResourceDictionary por origen

A partir de .NET Framework 4.7.2, un asistente de diagnóstico puede localizar los objetos ResourceDictionaries que se han creado desde un URI de origen determinado. (Esta característica la usan los asistentes de diagnóstico, no las aplicaciones de producción). Un asistente de diagnóstico, como la instalación "Editar y continuar" de Visual Studio permite al usuario editar un ResourceDictionary con la intención de aplicar los cambios a la aplicación en ejecución. Un paso para lograr esto es encontrar todos los ResourceDictionaries que la aplicación en ejecución ha creado a partir del diccionario que se está editando. Por ejemplo, una aplicación puede declarar un ResourceDictionary cuyo contenido se copia desde un URI de origen determinado:

<ResourceDictionary Source="MyRD.xaml" />

Un asistente de diagnóstico que edita el marcado original en MyRD.xaml puede usar la nueva característica para localizar el diccionario. La característica se implementa mediante un nuevo método estático, ResourceDictionaryDiagnostics.GetResourceDictionariesForSource. El asistente de diagnóstico llama al nuevo método mediante un URI absoluto que identifica el marcado original, como se muestra en el código siguiente:

IEnumerable<ResourceDictionary> dictionaries = ResourceDictionaryDiagnostics.GetResourceDictionariesForSource(new Uri("pack://application:,,,/MyApp;component/MyRD.xaml"));

Dim dictionaries As IEnumerable(Of ResourceDictionary) = ResourceDictionaryDiagnostics.GetResourceDictionariesForSource(New Uri("pack://application:,,,/MyApp;component/MyRD.xaml"))

El método devuelve un enumerable vacío a menos que VisualDiagnostics esté habilitado y se establezca la variable de entorno ENABLE_XAML_DIAGNOSTICS_SOURCE_INFO.

Encontrar a los propietarios de ResourceDictionary

A partir de .NET Framework 4.7.2, un asistente de diagnóstico puede localizar los propietarios de un ResourceDictionarydeterminado. (La característica la usan los asistentes de diagnóstico y no las aplicaciones de producción). Cada vez que se realiza un cambio en un ResourceDictionary, WPF busca automáticamente todas las referencias de DynamicResource que podrían verse afectadas por el cambio.

Un asistente de diagnóstico como la opción "Editar y continuar" de Visual Studio puede ampliar esta opción para controlar las referencias StaticResource. El primer paso de este proceso es buscar los propietarios del diccionario; es decir, para buscar todos los objetos cuya propiedad Resources hace referencia al diccionario (directa o indirectamente a través de la propiedad ResourceDictionary.MergedDictionaries). Tres nuevos métodos estáticos implementados en la clase System.Windows.Diagnostics.ResourceDictionaryDiagnostics, uno para cada uno de los tipos base que tienen una propiedad Resources, admiten este paso:

Estos métodos devuelven un enumerable vacío a menos que VisualDiagnostics esté habilitado y se establezca la variable de entorno ENABLE_XAML_DIAGNOSTICS_SOURCE_INFO.

Búsqueda de referencias de StaticResource

Ahora, un asistente de diagnóstico puede recibir una notificación cada vez que se resuelve una referencia de StaticResource. (La característica la usan los asistentes de diagnóstico, no las aplicaciones de producción). Es posible que un asistente de diagnóstico como la instalación "Editar y continuar" de Visual Studio quiera actualizar todos los usos de un recurso cuando cambia su valor en un ResourceDictionary. WPF lo hace automáticamente para referencias de DynamicResource , pero intencionadamente no lo hace para referencias de StaticResource . A partir de .NET Framework 4.7.2, el asistente de diagnóstico puede usar estas notificaciones para localizar esos usos del recurso estático.

La notificación se implementa mediante el nuevo evento ResourceDictionaryDiagnostics.StaticResourceResolved:

public static event EventHandler<StaticResourceResolvedEventArgs> StaticResourceResolved;

Public Shared Event StaticResourceResolved As EventHandler(Of StaticResourceResolvedEventArgs)

Este evento se genera cada vez que el tiempo de ejecución resuelve una referencia de StaticResource. Los argumentos de StaticResourceResolvedEventArgs describen la resolución e indican el objeto y la propiedad que hospedan la referencia StaticResource y el objeto ResourceDictionary y la clave que se usan para la resolución:

public class StaticResourceResolvedEventArgs : EventArgs
{
   public Object TargetObject { get; }

   public Object TargetProperty { get; }

   public ResourceDictionary ResourceDictionary { get; }

   public object ResourceKey { get; }
}

Public Class StaticResourceResolvedEventArgs : Inherits EventArgs
   Public ReadOnly Property TargetObject As Object
   Public ReadOnly Property TargetProperty As Object
   Public ReadOnly Property ResourceDictionary As ResourceDictionary
   Public ReadOnly Property ResourceKey As Object
End Class

El evento no se genera (y se omite su descriptor de acceso add), a menos que VisualDiagnostics esté habilitado y se establezca la variable de entorno ENABLE_XAML_DIAGNOSTICS_SOURCE_INFO.

ClickOnce

Las aplicaciones compatibles con HDPI para Windows Forms, Windows Presentation Foundation (WPF) y Visual Studio Tools para Office (VSTO) se pueden implementar mediante ClickOnce. Si se encuentra la siguiente entrada en el manifiesto de aplicación, la implementación se realizará correctamente en .NET Framework 4.7.2:

<windowsSettings>
   <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>
</windowsSettings>

Para la aplicación de Windows Forms, la solución anterior de establecer el reconocimiento de PPP en el archivo de configuración de la aplicación en lugar de en el manifiesto de aplicación ya no es necesaria para que la implementación de ClickOnce sea correcta.

Novedades de .NET Framework 4.7.1

.NET Framework 4.7.1 incluye nuevas características en las siguientes áreas:

Además, un enfoque importante en .NET Framework 4.7.1 es mejorar la accesibilidad, lo que permite a una aplicación proporcionar una experiencia adecuada para los usuarios de tecnología de asistencia. Para obtener información sobre las mejoras de accesibilidad en .NET Framework 4.7.1, consulte Novedades de accesibilidad en .NET Framework.

Clases base

Compatibilidad con .NET Standard 2.0

.NET Standard define un conjunto de API que deben estar disponibles en cada implementación de .NET que admita esa versión del estándar. .NET Framework 4.7.1 es totalmente compatible con .NET Standard 2.0 y agrega aproximadamente 200 API que se definen en .NET Standard 2.0 y que faltan en .NET Framework 4.6.1, 4.6.2 y 4.7. (Tenga en cuenta que estas versiones de .NET Framework admiten .NET Standard 2.0 solo si también se implementan archivos de compatibilidad adicionales de .NET Standard en el sistema de destino). Para obtener más información, vea "Compatibilidad con BCL - .NET Standard 2.0" en la entrada de blog runtime de .NET Framework 4.7.1 y Características del compilador.

compatibilidad con generadores de configuración

Los generadores de configuración permiten a los desarrolladores insertar y compilar opciones de configuración para aplicaciones dinámicamente en tiempo de ejecución. Los generadores de configuración personalizados se pueden usar para modificar los datos existentes en una sección de configuración o para crear una sección de configuración completamente desde cero. Sin los generadores de configuración, los archivos .config son estáticos y su configuración se define algún tiempo antes de que se inicie una aplicación.

Para crear un generador de configuración personalizado, derive el generador de la clase ConfigurationBuilder abstracta y reemplace sus métodos ConfigurationBuilder.ProcessConfigurationSection y ConfigurationBuilder.ProcessRawXml. También defines tus builders en el archivo .config. Para obtener más información, consulte la sección "Generadores de configuración" de la entrada de blog .NET Framework 4.7.1 ASP.NET y Características de configuración.

Detección de características en tiempo de ejecución

La clase System.Runtime.CompilerServices.RuntimeFeature proporciona un mecanismo para determinar si se admite una característica predefinida en una implementación de .NET determinada en tiempo de compilación o en tiempo de ejecución. En tiempo de compilación, un compilador puede comprobar si existe un campo especificado para determinar si se admite la característica; Si es así, puede emitir código que aproveche esa característica. En tiempo de ejecución, una aplicación puede llamar al método RuntimeFeature.IsSupported antes de emitir código en tiempo de ejecución. Para obtener más información, consulte Agregar método auxiliar para describir las características admitidas por el entorno de ejecución.

Los tipos value tuple son serializables

A partir de .NET Framework 4.7.1, System.ValueTuple y sus tipos genéricos asociados se marcan como Serializable, lo que permite la serialización binaria. Esto facilita la migración de tipos tuple, como Tuple<T1,T2,T3> y Tuple<T1,T2,T3,T4>, a tipos value tuple. Para más información, vea "Compiler -- ValueTuple is Serializable" (Compilador: ValueTuple serializable) en la entrada de blog .NET Framework 4.7.1 Runtime and Compiler Features (Características del compilador y del tiempo de ejecución de .NET Framework 4.7.1).

Compatibilidad con referencias de solo lectura

.NET Framework 4.7.1 agrega System.Runtime.CompilerServices.IsReadOnlyAttribute. Los compiladores de lenguaje utilizan este atributo para marcar los miembros que tienen parámetros o tipos de valor devuelto con referencias de solo lectura. Para obtener más información, vea "Compilador: compatibilidad con ReadOnlyReferences" en la entrada de blog .NET Framework 4.7.1 Runtime and Compiler Features. Para obtener información sobre los valores devueltos por referencia, consulte Valores devueltos por referencia, Variables locales de tipo ref y Compatibilidad con valores devueltos de referencia (Visual Basic).

Common Language Runtime (CLR) (Entorno de ejecución común)

mejoras en el rendimiento de la recolección de basura

Los cambios en la recolección de elementos no utilizados en .NET Framework 4.7.1 mejoran el rendimiento general, sobre todo para las asignaciones del montón de objetos grandes. En .NET Framework 4.7.1, se usan bloqueos independientes para las asignaciones de montón de objetos pequeños y de montón de objetos grandes, lo que permite que se realicen asignaciones de montón de objetos grandes cuando la operación de recolección de elementos no utilizados en segundo plano barre el montón de objetos pequeños. Como resultado, las aplicaciones que realizan un número elevado de asignaciones de montón de objetos grandes deben observar una reducción de la contención del bloqueo de asignación y un rendimiento mejorado. Para obtener más información, consulte la sección "Runtime - GC Performance Improvements" (Mejoras de rendimiento de GC) en la entrada de blog .NET Framework 4.7.1 Runtime and Compiler Features .

Gestión de redes

Compatibilidad de SHA-2 con Message.HashAlgorithm

En .NET Framework 4.7 y versiones anteriores, la propiedad Message.HashAlgorithm solo admite valores de HashAlgorithm.Md5 y HashAlgorithm.Sha. A partir de .NET Framework 4.7.1, también se admiten HashAlgorithm.Sha256, HashAlgorithm.Sha384y HashAlgorithm.Sha512. Si este valor se usa realmente depende de MSMQ, ya que la propia instancia de Message no realiza ningún hash, sino que simplemente pasa valores a MSMQ. Para obtener más información, consulte la sección "Compatibilidad de SHA-2 con Message.HashAlgorithm" en la entrada de blog .NET Framework 4.7.1 ASP.NET y Características de configuración.

ASP.NET

Pasos de ejecución en aplicaciones ASP.NET

ASP.NET procesa las solicitudes en una canalización predefinida que incluye 23 eventos. ASP.NET ejecuta cada controlador de eventos como paso de ejecución. En versiones de ASP.NET hasta .NET Framework 4.7, ASP.NET no puede propagar el contexto de ejecución debido al cambio entre subprocesos nativos y administrados. En su lugar, ASP.NET propaga de forma selectiva solo el HttpContext. A partir de .NET Framework 4.7.1, el método HttpApplication.OnExecuteRequestStep(Action<HttpContextBase,Action>) también permite a los módulos restaurar datos ambientales. Esta característica está destinada a bibliotecas relacionadas con el seguimiento, la generación de perfiles, los diagnósticos o las transacciones, por ejemplo, que se preocupan por el flujo de ejecución de la aplicación. Para obtener más información, consulte "Características de paso de ejecución de ASP.NET" en la entrada del blog .NET Framework 4.7.1 ASP.NET y Características de configuración.

Análisis HttpCookie de ASP.NET

.NET Framework 4.7.1 incluye un nuevo método, HttpCookie.TryParse, que proporciona una manera estandarizada de crear un objeto HttpCookie a partir de una cadena y asignar con precisión valores de cookies, como la fecha de expiración y la ruta de acceso. Para más información, vea la sección "ASP.NET HttpCookie parsing" (Análisis HttpCookie de ASP.NET) en la entrada de blog .NET Framework 4.7.1 ASP.NET and Configuration Features (Características de configuración y ASP.NET en .NET Framework 4.7.1).

Compatibilidad con opciones hash SHA-2 para las credenciales de autenticación de formularios de ASP.NET

En .NET Framework 4.7 y versiones anteriores, ASP.NET permitió a los desarrolladores almacenar credenciales de usuario con contraseñas hash en archivos de configuración mediante MD5 o SHA1. A partir de .NET Framework 4.7.1, ASP.NET también admite nuevas opciones de hash SHA-2 seguras, como SHA256, SHA384 y SHA512. SHA1 sigue siendo el valor predeterminado y se puede definir un algoritmo hash no predeterminado en el archivo de configuración web.

Importante

Microsoft recomienda usar el flujo de autenticación más seguro disponible. Si se conecta a Azure SQL, el uso de Identidades Administradas para Recursos de Azure es el método de autenticación recomendado.

Novedades de .NET Framework 4.7

.NET Framework 4.7 incluye nuevas características en las siguientes áreas:

Para obtener una lista de las nuevas API agregadas a .NET Framework 4.7, consulte .NET Framework 4.7 API Changes on GitHub (Cambios de API de .NET Framework 4.7 en GitHub). Para obtener una lista de las mejoras de características y correcciones de errores en .NET Framework 4.7, consulte .NET Framework 4.7 Lista de cambios en GitHub. Para obtener más información, consulte Anunciando .NET Framework 4.7 en el blog de .NET.

Clases base

.NET Framework 4.7 mejora la serialización mediante el DataContractJsonSerializer:

funcionalidad mejorada con criptografía de curva elíptica (ECC)*

En .NET Framework 4.7, los métodos ImportParameters(ECParameters) se agregaron a la ECDsa y ECDiffieHellman clases para permitir que un objeto represente una clave ya establecida. También se agregó un método ExportParameters(Boolean) para exportar la clave mediante parámetros de curva explícitos.

.NET Framework 4.7 también agrega compatibilidad con curvas adicionales (incluido el conjunto de curvas Brainpool) y ha agregado definiciones predefinidas para facilitar la creación a través de los nuevos métodos de fábrica de Create y Create.

Puede ver un ejemplo de las mejoras de criptografía de .NET Framework 4.7 en GitHub.

Mejor compatibilidad con los caracteres de control a cargo de DataContractJsonSerializer.

En .NET Framework 4.7, la clase DataContractJsonSerializer serializa los caracteres de control de conformidad con el estándar ECMAScript 6. Este comportamiento está habilitado de forma predeterminada para las aplicaciones que tienen como destino .NET Framework 4.7 y es una característica de participación para las aplicaciones que se ejecutan en .NET Framework 4.7, pero tienen como destino una versión anterior de .NET Framework. Para obtener más información, consulte la sección compatibilidad de aplicaciones.

Gestión de redes

.NET Framework 4.7 agrega la siguiente característica relacionada con la red:

compatibilidad predeterminada del sistema operativo con protocolos TLS*

La pila TLS, que usa System.Net.Security.SslStream y componentes de pila superior, como HTTP, FTP y SMTP, permite a los desarrolladores usar los protocolos TLS predeterminados compatibles con el sistema operativo. Los desarrolladores ya no necesitan codificar de forma rígida una versión de TLS.

ASP.NET

En .NET Framework 4.7, ASP.NET incluye las siguientes características nuevas:

Extensibilidad de caché de objetos

A partir de .NET Framework 4.7, ASP.NET agrega un nuevo conjunto de API que permiten a los desarrolladores reemplazar las implementaciones de ASP.NET predeterminadas para el almacenamiento en caché de objetos en memoria y la supervisión de memoria. Los desarrolladores ahora pueden reemplazar cualquiera de los tres componentes siguientes si la implementación de ASP.NET no es adecuada:

  • Almacén de caché de objetos. Mediante la nueva sección de configuración de proveedores de caché, los desarrolladores pueden conectar nuevas implementaciones de una caché de objetos para una aplicación de ASP.NET mediante la nueva interfaz de ICacheStoreProvider.

  • Supervisión de memoria. El monitor de memoria predeterminado de ASP.NET notifica a las aplicaciones cuando se ejecutan cerca del límite de bytes privados configurados para el proceso o cuando la máquina es baja en la RAM física total disponible. Cuando estos límites están cerca, se activan las notificaciones. En algunas aplicaciones, las notificaciones se activan demasiado cerca de los límites configurados para permitir reacciones útiles. Los desarrolladores ahora pueden usar la propiedad ApplicationMonitors.MemoryMonitor para escribir sus propios monitores de memoria y, así, reemplazar el predeterminado.

  • Reacciones por límite de memoria. De forma predeterminada, ASP.NET intenta recortar la memoria caché de objetos y llama periódicamente a GC.Collect cuando el límite de proceso de bytes privado está cerca. En algunas aplicaciones, la frecuencia de las llamadas a GC.Collect o la cantidad de caché que se recorta son ineficaz. Los desarrolladores ahora pueden reemplazar o complementar el comportamiento predeterminado al suscribir implementaciones de IObserver al monitor de memoria de la aplicación.

Windows Communication Foundation (WCF)

Windows Communication Foundation (WCF) agrega las siguientes características y cambios:

Capacidad de configurar las opciones de seguridad de mensajes predeterminadas en TLS 1.1 o TLS 1.2

A partir de .NET Framework 4.7, WCF permite configurar TLS 1.1 o TLS 1.2 además de SSL 3.0 y TLS 1.0 como protocolo de seguridad de mensajes predeterminado. Se trata de una configuración de participación; para habilitarlo, debe agregar la siguiente entrada al archivo de configuración de la aplicación:

<runtime>
   <AppContextSwitchOverrides value="Switch.System.ServiceModel.DisableUsingServicePointManagerSecurityProtocols=false;Switch.System.Net.DontEnableSchUseStrongCrypto=false" />
</runtime>

Confiabilidad mejorada de las aplicaciones WCF y la serialización WCF

WCF incluye una serie de cambios de código que eliminan las condiciones de carrera, lo que mejora el rendimiento y la confiabilidad de las opciones de serialización. Estos incluyen:

  • Mayor compatibilidad para combinar código asincrónico y sincrónico en las llamadas a SocketConnection.BeginRead y SocketConnection.Read.
  • Confiabilidad mejorada cuando se anula una conexión con SharedConnectionListener y DuplexChannelBinder.
  • Se ha mejorado la confiabilidad de las operaciones de serialización al llamar al método FormatterServices.GetSerializableMembers(Type).
  • Se ha mejorado la confiabilidad al quitar un waiter llamando al método ChannelSynchronizer.RemoveWaiter.

Windows Forms

En .NET Framework 4.7, Windows Forms mejora la compatibilidad con monitores de alta DPI.

Compatibilidad con valores altos de PPP

A partir de las aplicaciones dirigidas a .NET Framework 4.7, .NET Framework ofrece soporte para alta DPI y DPI dinámica en las aplicaciones de Windows Forms. La compatibilidad con valores altos de DPI mejora el diseño y la apariencia de los formularios y controles en monitores de alta resolución. DPI dinámico cambia el diseño y la apariencia de los formularios y controles cuando el usuario cambia el DPI o el factor de escala de visualización de una aplicación en ejecución.

La compatibilidad con valores altos de PPP es una característica opcional. Para configurarla, debe definirse una sección <System.Windows.Forms.ConfigurationSection> en el archivo de configuración de la aplicación. Para más información sobre cómo agregar compatibilidad con valores altos de PPP y PPP dinámicos a la aplicación de Windows Forms, consulte Compatibilidad con valores altos de PPP en Windows Forms.

Windows Presentation Foundation (WPF)

En .NET Framework 4.7, WPF incluye las siguientes mejoras:

Compatibilidad con una pila de entrada táctil o de lápiz basada en mensajes WM_POINTER de Windows

Ahora tiene la opción de usar una pila de entrada táctil o de lápiz basada en mensajes WM_POINTER en lugar de Windows Ink Services Platform (WISP). Es una función opcional en .NET Framework. Para obtener más información, consulte la sección Compatibilidad de aplicaciones.

nueva implementación de las API de impresión de WPF

Las APIs de impresión de WPF en la clase System.Printing.PrintQueue llaman a la API de Windows para el paquete de documentos de impresión en lugar de la API de impresión XPS obsoleta . Para ver el impacto de este cambio en la compatibilidad de aplicaciones, consulte la sección Compatibilidad de aplicaciones.

Novedades de .NET Framework 4.6.2

.NET Framework 4.6.2 incluye nuevas características en las siguientes áreas:

Para obtener una lista de las nuevas API agregadas a .NET Framework 4.6.2, consulte Cambios de API en .NET Framework 4.6.2 en GitHub. Para obtener una lista de las mejoras de características y correcciones de errores en .NET Framework 4.6.2, consulte .NET Framework 4.6.2 Lista de cambios en GitHub. Para obtener más información, consulte Anuncio de .NET Framework 4.6.2 en el blog de .NET.

ASP.NET

En .NET Framework 4.6.2, ASP.NET incluye las siguientes mejoras:

compatibilidad mejorada con mensajes de error localizados en validadores de anotaciones de datos

Los validadores de anotación de datos permiten realizar la validación agregando uno o varios atributos a una propiedad de clase. El elemento ValidationAttribute.ErrorMessage del atributo define el texto del mensaje de error si se produce un error en la validación. A partir de .NET Framework 4.6.2, ASP.NET facilita la localización de mensajes de error. Los mensajes de error se localizarán si:

  1. El ValidationAttribute.ErrorMessage se proporciona en el atributo de validación.

  2. El archivo de recursos se almacena en la carpeta App_LocalResources.

  3. El nombre del archivo de recursos localizados tiene la forma DataAnnotation.Localization.{nombre}.resx, donde nombre es un nombre de referencia cultural en el formato códigoDeIdioma-códigoDePaís/Región o códigoDeIdioma.

  4. El nombre de clave del recurso es la cadena asignada al atributo ValidationAttribute.ErrorMessage y su valor es el mensaje de error localizado.

Por ejemplo, el siguiente atributo de anotación de datos define el mensaje de error de la referencia cultural predeterminada para una clasificación no válida.

public class RatingInfo
{
   [Required(ErrorMessage = "The rating must be between 1 and 10.")]
   [Display(Name = "Your Rating")]
   public int Rating { get; set; }
}

Public Class RatingInfo
   <Required(ErrorMessage = "The rating must be between 1 and 10.")>
   <Display(Name = "Your Rating")>
   Public Property Rating As Integer = 1
End Class

A continuación, puede crear un archivo de recursos, DataAnnotation.Localization.fr.resx, cuya clave es la cadena del mensaje de error y cuyo valor es el mensaje de error localizado. El archivo debe encontrarse en la carpeta App.LocalResources. Por ejemplo, lo siguiente es la clave y su valor en un mensaje de error de idioma francés localizado (fr):

Nombre Valor
La clasificación debe estar entre 1 y 10. La nota debe estar comprendida entre 1 y 10.

Además, la localización de anotaciones de datos es extensible. Los desarrolladores pueden conectar su propio proveedor de localizador de cadenas implementando la interfaz de IStringLocalizerProvider para almacenar la cadena de localización en algún lugar distinto de un archivo de recursos.

Soporte asincrónico con proveedores de almacenamiento de estado de sesión

Actualmente, ASP.NET permite el uso de métodos de devolución de tareas con proveedores de almacenes de estados de sesión, lo que permite que las aplicaciones ASP.NET aprovechen las ventajas de escalabilidad de la asincronía. Para admitir operaciones asincrónicas con proveedores de almacén de estado de sesión, ASP.NET incluye una nueva interfaz, System.Web.SessionState.ISessionStateModule, que hereda de IHttpModule y permite a los desarrolladores implementar su propio módulo de estado de sesión y proveedores de almacén de sesión asincrónicos. La interfaz se define de la siguiente manera:

public interface ISessionStateModule : IHttpModule {
    void ReleaseSessionState(HttpContext context);
    Task ReleaseSessionStateAsync(HttpContext context);
}

Public Interface ISessionStateModule : Inherits IHttpModule
   Sub ReleaseSessionState(context As HttpContext)
   Function ReleaseSessionStateAsync(context As HttpContext) As Task
End Interface

Además, la clase SessionStateUtility incluye dos métodos nuevos, IsSessionStateReadOnly y IsSessionStateRequired, que se pueden usar para admitir operaciones asincrónicas.

Compatibilidad asincrónica con proveedores de caché de salida

A partir de .NET Framework 4.6.2, los métodos de devolución de tareas se pueden usar con proveedores de caché de salida para proporcionar las ventajas de escalabilidad de async. Los proveedores que implementan estos métodos reducen el bloqueo de subprocesos en un servidor web y mejoran la escalabilidad de un servicio ASP.NET.

Se han agregado las SIGUIENTES API para admitir proveedores asincrónicos de caché de salida:

Categorías de caracteres

Los caracteres de .NET Framework 4.6.2 se clasifican en función del estándar Unicode de , versión 8.0.0. En .NET Framework 4.6 y .NET Framework 4.6.1, los caracteres se clasificaron en función de categorías de caracteres Unicode 6.3.

La compatibilidad con Unicode 8.0 se limita a la clasificación de caracteres por la clase CharUnicodeInfo y a los tipos y métodos que se basan en él. Entre ellas se incluyen la clase StringInfo, el método Char.GetUnicodeCategory sobrecargado y las clases de caracteres reconocidas por el motor de expresiones regulares de .NET Framework. La comparación y ordenación de caracteres y cadenas no se ve afectada por este cambio y sigue confiando en el sistema operativo subyacente o, en los sistemas Windows 7, en los datos de caracteres proporcionados por .NET Framework.

Para ver los cambios en las categorías de caracteres de Unicode 6.0 a Unicode 7.0, consulte El estándar Unicode, versión 7.0.0 en el sitio web del Consorcio Unicode. Para ver los cambios de Unicode 7.0 a Unicode 8.0, consulte El estándar Unicode, versión 8.0.0 en el sitio web del Consorcio Unicode.

Criptografía

Compatibilidad con certificados X509 que contienen DSA FIPS 186-3

.NET Framework 4.6.2 agrega compatibilidad con certificados X509 de DSA (algoritmo de firma digital) cuyas claves superan el límite de 186-2 de FIPS 1024 bits.

Además de admitir los tamaños de clave más grandes de FIPS 186-3, .NET Framework 4.6.2 permite calcular firmas con la familia sha-2 de algoritmos hash (SHA256, SHA384 y SHA512). La nueva clase System.Security.Cryptography.DSACng proporciona compatibilidad con FIPS 186-3.

En consonancia con los cambios recientes en la clase RSA del .NET Framework 4.6 y la clase ECDsa en .NET Framework 4.6.1, la clase base abstracta DSA en .NET Framework 4.6.2 tiene métodos adicionales para permitir que los usuarios utilicen esta funcionalidad sin necesidad de hacer un casting. Puede llamar al método de extensión DSACertificateExtensions.GetDSAPrivateKey para firmar datos, como se muestra en el ejemplo siguiente.

public static byte[] SignDataDsaSha384(byte[] data, X509Certificate2 cert)
{
    using (DSA dsa = cert.GetDSAPrivateKey())
    {
        return dsa.SignData(data, HashAlgorithmName.SHA384);
    }
}

Public Shared Function SignDataDsaSha384(data As Byte(), cert As X509Certificate2) As Byte()
    Using DSA As DSA = cert.GetDSAPrivateKey()
        Return DSA.SignData(data, HashAlgorithmName.SHA384)
    End Using
End Function

Y puede llamar al método de extensión DSACertificateExtensions.GetDSAPublicKey para comprobar los datos firmados, como se muestra en el ejemplo siguiente.

public static bool VerifyDataDsaSha384(byte[] data, byte[] signature, X509Certificate2 cert)
{
    using (DSA dsa = cert.GetDSAPublicKey())
    {
        return dsa.VerifyData(data, signature, HashAlgorithmName.SHA384);
    }
}

 Public Shared Function VerifyDataDsaSha384(data As Byte(), signature As Byte(), cert As X509Certificate2) As Boolean
    Using dsa As DSA = cert.GetDSAPublicKey()
        Return dsa.VerifyData(data, signature, HashAlgorithmName.SHA384)
    End Using
End Function

Mayor claridad para las entradas en rutinas de derivación de claves ECDiffieHellman

.NET Framework 3.5 ha agregado compatibilidad con el acuerdo de clave de curva elíptica Diffie-Hellman con tres funciones de derivación de clave (KDF) diferentes. Las entradas a las rutinas y las propias rutinas se configuraron a través de propiedades en el objeto ECDiffieHellmanCng. Pero como no todas las rutinas leían todas las propiedades de entrada, esto podía provocar confusión al desarrollador.

Para abordar esto en .NET Framework 4.6.2, se han agregado los tres métodos siguientes a la clase base ECDiffieHellman para representar con más claridad estas rutinas de KDF y sus entradas:

Método ECDiffieHellman Descripción
DeriveKeyFromHash(ECDiffieHellmanPublicKey, HashAlgorithmName, Byte[], Byte[]) Deriva material clave mediante la fórmula

HASH(secretPrepend || x || secretAppend)

HASH(secretPrepend OrElse x OrElse secretAppend)

donde x es el resultado calculado del algoritmo de Diffie-Hellman EC.
DeriveKeyFromHmac(ECDiffieHellmanPublicKey, HashAlgorithmName, Byte[], Byte[], Byte[]) Deriva material clave mediante la fórmula

HMAC(hmacKey, secretPrepend || x || secretAppend)

HMAC(hmacKey, secretPrepend OrElse x OrElse secretAppend)

donde x es el resultado calculado del algoritmo de Diffie-Hellman EC.
DeriveKeyTls(ECDiffieHellmanPublicKey, Byte[], Byte[]) Deriva el material de clave mediante el algoritmo de derivación de función pseudoaleatoria (PRF) de TLS.

compatibilidad con el cifrado simétrico de clave persistente

La biblioteca de criptografía de Windows (CNG) agregó compatibilidad para almacenar claves simétricas persistentes y usar claves simétricas almacenadas por hardware y .NET Framework 4.6.2 hizo posible que los desarrolladores usen esta característica. Dado que la noción de nombres de clave y proveedores de claves es específica de la implementación, utilizar esta característica requiere emplear el constructor de los tipos de implementación concretos en lugar del enfoque de fábrica preferido (por ejemplo, llamar a Aes.Create).

Existe compatibilidad con el cifrado simétrico de clave persistente para los algoritmos AES (AesCng) y 3DES (TripleDESCng). Por ejemplo:

public static byte[] EncryptDataWithPersistedKey(byte[] data, byte[] iv)
{
    using (Aes aes = new AesCng("AesDemoKey", CngProvider.MicrosoftSoftwareKeyStorageProvider))
    {
        aes.IV = iv;

        // Using the zero-argument overload is required to make use of the persisted key
        using (ICryptoTransform encryptor = aes.CreateEncryptor())
        {
            if (!encryptor.CanTransformMultipleBlocks)
            {
                throw new InvalidOperationException("This is a sample, this case wasn't handled...");
            }

            return encryptor.TransformFinalBlock(data, 0, data.Length);
        }
    }
}

Public Shared Function EncryptDataWithPersistedKey(data As Byte(), iv As Byte()) As Byte()
    Using Aes As Aes = New AesCng("AesDemoKey", CngProvider.MicrosoftSoftwareKeyStorageProvider)
        Aes.IV = iv

        ' Using the zero-argument overload Is required to make use of the persisted key
        Using encryptor As ICryptoTransform = Aes.CreateEncryptor()
            If Not encryptor.CanTransformMultipleBlocks Then
                Throw New InvalidOperationException("This is a sample, this case wasn't handled...")
            End If
            Return encryptor.TransformFinalBlock(data, 0, data.Length)
        End Using
    End Using
End Function

Compatibilidad con SignedXml para hash SHA-2

.NET Framework 4.6.2 agrega compatibilidad con la clase SignedXml para los métodos de firma RSA-SHA256, RSA-SHA384 y RSA-SHA512 PKCS#1, y para los algoritmos de resumen de referencia SHA256, SHA384 y SHA512.

Todas las constantes de URI se exponen en SignedXml:

Campo SignedXml Constante
XmlDsigSHA256Url "http://www.w3.org/2001/04/xmlenc#sha256"
XmlDsigRSASHA256Url "http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"
XmlDsigSHA384Url "http://www.w3.org/2001/04/xmldsig-more#sha384"
XmlDsigRSASHA384Url "http://www.w3.org/2001/04/xmldsig-more#rsa-sha384"
XmlDsigSHA512Url "http://www.w3.org/2001/04/xmlenc#sha512"
XmlDsigRSASHA512Url "http://www.w3.org/2001/04/xmldsig-more#rsa-sha512"

Los programas que han registrado un controlador de SignatureDescription personalizado en CryptoConfig para agregar compatibilidad con estos algoritmos seguirán funcionando como lo hicieron en el pasado, pero dado que ahora hay valores predeterminados de la plataforma, el registro de CryptoConfig ya no es necesario.

SqlClient

El proveedor de datos de .NET Framework para SQL Server (System.Data.SqlClient) incluye las siguientes características nuevas en .NET Framework 4.6.2:

Agrupación de conexiones y tiempos de espera en bases de datos de Azure SQL

Cuando la agrupación de conexiones está habilitada y se produce un tiempo de espera u otro error de inicio de sesión, se almacena en caché una excepción y la excepción almacenada en caché se inicia en cualquier intento de conexión posterior durante los próximos 5 segundos a 1 minuto. Para obtener más información, vea Agrupación de conexiones de SQL Server (ADO.NET).

Este comportamiento no es deseable al conectarse a bases de datos de Azure SQL, ya que los intentos de conexión pueden producir errores transitorios que normalmente se recuperan rápidamente. Para optimizar mejor la experiencia de reintento de conexión, se elimina el comportamiento del período de bloqueo del grupo de conexiones cuando fallan las conexiones a Azure SQL Databases.

La adición de la nueva palabra clave PoolBlockingPeriod permite seleccionar el período de bloqueo más adecuado para la aplicación. Los valores incluyen:

Auto

El período de bloqueo del grupo de conexiones para una aplicación que se conecta a una instancia de Azure SQL Database está deshabilitado y el período de bloqueo del grupo de conexiones para una aplicación que se conecta a cualquier otra instancia de SQL Server está habilitada. Este es el valor predeterminado. Si el nombre del punto de conexión del servidor finaliza con cualquiera de las siguientes opciones, se consideran bases de datos de Azure SQL:

  • .database.windows.net

  • .database.chinacloudapi.cn

  • .database.usgovcloudapi.net

  • .database.cloudapi.de

AlwaysBlock

El período de bloqueo del grupo de conexiones siempre está habilitado.

NeverBlock

El período de bloqueo del grupo de conexión siempre está deshabilitado.

Mejoras para Always Encrypted

SQLClient presenta dos mejoras para Always Encrypted:

  • Para mejorar el rendimiento de las consultas con parámetros en columnas de base de datos cifradas, los metadatos de cifrado para los parámetros de consulta ahora se almacenan en caché. Con la propiedad SqlConnection.ColumnEncryptionQueryMetadataCacheEnabled establecida en true (que es el valor predeterminado), si se llama a la misma consulta varias veces, el cliente recupera los metadatos de parámetro del servidor solo una vez.

  • Las entradas de clave de cifrado de columnas de la caché de claves ahora se expulsan después de un intervalo de tiempo configurable, establecido mediante la propiedad SqlConnection.ColumnEncryptionKeyCacheTtl.

Windows Communication Foundation

En .NET Framework 4.6.2, Windows Communication Foundation se ha mejorado en las siguientes áreas:

Compatibilidad con la seguridad de transporte de WCF para los certificados almacenados con CNG

La seguridad de transporte de WCF admite certificados almacenados mediante la biblioteca de criptografía de Windows (CNG). En .NET Framework 4.6.2, esta compatibilidad se limita a usar certificados con una clave pública que tenga un exponente que no tenga más de 32 bits de longitud. Cuando una aplicación tiene como destino .NET Framework 4.6.2, esta característica está activada de forma predeterminada.

En el caso de las aplicaciones que tienen como destino .NET Framework 4.6.1 y versiones anteriores, pero que se ejecutan en .NET Framework 4.6.2, esta característica se puede habilitar agregando la línea siguiente a la sección en tiempo de ejecución de del archivo app.config o web.config.

<AppContextSwitchOverrides
    value="Switch.System.IdentityModel.DisableCngCertificates=false"
/>

Esto también se puede hacer mediante programación con código como el siguiente:

private const string DisableCngCertificates = @"Switch.System.IdentityModel.DisableCngCertificates";
AppContext.SetSwitch(disableCngCertificates, false);

Const DisableCngCertificates As String = "Switch.System.IdentityModel.DisableCngCertificates"
AppContext.SetSwitch(disableCngCertificates, False)

Mejor compatibilidad para varias reglas de ajuste al horario de verano mediante la clase DataContractJsonSerializer

Los clientes pueden usar una configuración de aplicación para determinar si la clase DataContractJsonSerializer admite varias reglas de ajuste para una sola zona horaria. Esta es una función opcional. Para habilitarlo, agregue la siguiente configuración al archivo app.config:

<runtime>
     <AppContextSwitchOverrides value="Switch.System.Runtime.Serialization.DoNotUseTimeZoneInfo=false" />
</runtime>

Cuando esta característica está habilitada, un objeto DataContractJsonSerializer usa el tipo TimeZoneInfo en lugar del tipo de TimeZone para deserializar los datos de fecha y hora. TimeZoneInfo admite varias reglas de ajuste, lo que permite trabajar con datos históricos de zona horaria; TimeZone no.

Para obtener más información sobre la estructura de TimeZoneInfo y los ajustes de zona horaria, consulte Información general sobre la zona horaria.

Mejor coincidencia de NetNamedPipeBinding

WCF tiene una nueva opción de la aplicación que se puede establecer en las aplicaciones cliente para garantizar que siempre se conecten al servicio que escucha en el URI que mejor coincida con el que solicitan. Con esta configuración de aplicación establecida en false (valor predeterminado), es posible que los clientes que usen NetNamedPipeBinding intenten conectarse a un servicio que escucha en un URI que sea una subcadena del URI solicitado.

Por ejemplo, un cliente intenta conectarse a un servicio que escucha en net.pipe://localhost/Service1, pero un servicio diferente en esa máquina que se ejecuta con privilegios de administrador está escuchando en net.pipe://localhost. Con esta configuración de aplicación establecida en false, el cliente intentaría conectarse al servicio incorrecto. Después de establecer la configuración de la aplicación en true, el cliente siempre se conectará al mejor servicio coincidente.

Nota

Los clientes que usan NetNamedPipeBinding buscar servicios en función de la dirección base del servicio (si existe) en lugar de la dirección del punto de conexión completo. Para asegurarse de que esta configuración siempre funciona, el servicio debe usar una dirección base única.

Para habilitar este cambio, agregue la siguiente configuración de aplicación al archivo App.config o Web.config de la aplicación cliente:

<configuration>
    <appSettings>
        <add key="wcf:useBestMatchNamedPipeUri" value="true" />
    </appSettings>
</configuration>

SSL 3.0 no es un protocolo predeterminado

Cuando se usa NetTcp con seguridad de transporte y un tipo de credencial de certificado, SSL 3.0 ya no es un protocolo predeterminado que se usa para negociar una conexión segura. En la mayoría de los casos, no debería haber ningún impacto en las aplicaciones existentes, ya que TLS 1.0 se incluye en la lista de protocolos para NetTcp. Todos los clientes existentes deben poder negociar una conexión mediante al menos TLS 1.0. Si se requiere Ssl3, use uno de los siguientes mecanismos de configuración para agregarlo a la lista de protocolos negociados.

Windows Presentation Foundation (WPF)

En .NET Framework 4.6.2, Windows Presentation Foundation se ha mejorado en las siguientes áreas:

Ordenación de grupos

Una aplicación que usa un objeto CollectionView para agrupar datos ahora puede declarar explícitamente cómo ordenar los grupos. La ordenación explícita soluciona el problema de la ordenación no intuitiva que se produce cuando una aplicación agrega o quita grupos dinámicamente, o cuando cambia el valor de las propiedades de elemento implicadas en la agrupación. También puede mejorar el rendimiento del proceso de creación de grupos moviendo comparaciones de las propiedades de agrupación del tipo de la colección completa al tipo de los grupos.

Para admitir la ordenación de grupos, las nuevas propiedades GroupDescription.SortDescriptions y GroupDescription.CustomSort describen cómo ordenar la colección de grupos generados por el objeto GroupDescription. Esto es análogo a la forma en que las propiedades de ListCollectionView con nombre idéntico describen cómo ordenar los elementos de datos.

Se pueden usar dos nuevas propiedades estáticas de la clase PropertyGroupDescription, CompareNameAscending y CompareNameDescending, para los casos más comunes.

Por ejemplo, los siguientes datos de grupos XAML por edad, ordenan los grupos de edad en orden ascendente y agrupan los elementos dentro de cada grupo de edad por apellido.

<GroupDescriptions>
     <PropertyGroupDescription
         PropertyName="Age"
         CustomSort=
              "{x:Static PropertyGroupDescription.CompareNamesAscending}"/>
     </PropertyGroupDescription>
</GroupDescriptions>

<SortDescriptions>
     <SortDescription PropertyName="LastName"/>
</SortDescriptions>

Soporte para teclado táctil

La compatibilidad con el teclado táctil permite el seguimiento del foco en aplicaciones WPF al invocar y descartar automáticamente el teclado táctil en Windows 10 cuando un control recibe entrada táctil que puede aceptar entrada de texto.

En versiones anteriores de .NET Framework, las aplicaciones WPF no pueden participar en el seguimiento de foco sin deshabilitar la compatibilidad con gestos táctiles o de lápiz de WPF. Como resultado, las aplicaciones WPF deben elegir entre el soporte táctil completo de WPF o confiar en la funcionalidad del ratón de Windows.

PPP por monitor

Para admitir la reciente proliferación de entornos con valores altos o híbridos de PPP para las aplicaciones WPF, WPF en .NET Framework 4.6.2 habilita el reconocimiento de monitor. Consulte los ejemplos de y la guía para desarrolladores en GitHub para obtener más información sobre cómo habilitar la aplicación WPF para que sea compatible con reconocimiento DPI por monitor.

En versiones anteriores de .NET Framework, las aplicaciones WPF tienen habilitado el reconocimiento de PPP del sistema. En otras palabras, el sistema operativo escala la interfaz de usuario de la aplicación según corresponda, según el PPP del monitor en el que se representa la aplicación.

Para las aplicaciones que se ejecutan con .NET Framework 4.6.2, puede deshabilitar los cambios de DPI por monitor en aplicaciones de WPF agregando una instrucción de configuración a la sección <en tiempo de ejecución> del archivo de configuración de la aplicación, como se indica a continuación:

<runtime>
   <AppContextSwitchOverrides value="Switch.System.Windows.DoNotScaleForDpiChanges=false"/>
</runtime>

Windows Workflow Foundation (WF)

En .NET Framework 4.6.2, Windows Workflow Foundation se ha mejorado en el área siguiente:

Compatibilidad con expresiones de C# e IntelliSense en el Diseñador de WF rehospedado

A partir de .NET Framework 4.5, WF admite expresiones de C# en el Diseñador de Visual Studio y en flujos de trabajo de código. El Diseñador de flujos de trabajo rehospedado es una característica clave de WF que permite que el Diseñador de flujos de trabajo esté en una aplicación fuera de Visual Studio (por ejemplo, en WPF). Windows Workflow Foundation proporciona la capacidad de admitir expresiones de C# e IntelliSense en el Diseñador de flujos de trabajo rehospedados. Para obtener más información, consulta el blog de Windows Workflow Foundation.

Availability of IntelliSense when a customer rebuilds a workflow project from Visual Studio En versiones de .NET Framework anteriores a la 4.6.2, IntelliSense del Diseñador WF se interrumpe cuando un cliente vuelve a generar un proyecto de flujo de trabajo desde Visual Studio. Aunque la compilación del proyecto es exitosa, los tipos de flujo de trabajo no se encuentran en el diseñador, y las advertencias de IntelliSense por los tipos de flujo de trabajo ausentes aparecen en la ventana de lista de errores . .NET Framework 4.6.2 soluciona este problema y hace que IntelliSense esté disponible.

Las aplicaciones de flujo de trabajo V1 con Seguimiento de Flujo de Trabajo ahora funcionan en modo FIPS

Las máquinas con el modo de cumplimiento FIPS habilitado ahora pueden ejecutar correctamente una aplicación de estilo Versión 1 con el seguimiento de flujo de trabajo activado. Para habilitar este escenario, debe realizar el siguiente cambio en el archivo app.config:

<add key="microsoft:WorkflowRuntime:FIPSRequired" value="true" />

Si este escenario no está habilitado, la ejecución de la aplicación continúa generando una excepción con el mensaje "Esta implementación no forma parte de los algoritmos criptográficos validados por FIPS de la Plataforma Windows".

Mejoras de Flujo de Trabajo al Usar la Actualización Dinámica con el Diseñador de Flujo de Trabajo de Visual Studio

El Diseñador de Flujos de Trabajo, el Diseñador de Actividades FlowChart y otros Diseñadores de Actividades de Flujos de Trabajo ahora cargan y muestran exitosamente los flujos de trabajo que se han guardado después de llamar al método DynamicUpdateServices.PrepareForUpdate. En versiones de .NET Framework anteriores a .NET Framework 4.6.2, cargar un archivo XAML en Visual Studio para un flujo de trabajo que se ha guardado después de llamar a DynamicUpdateServices.PrepareForUpdate puede dar lugar a los siguientes problemas:

  • El Diseñador de flujos de trabajo no puede cargar el archivo XAML correctamente (cuando el ViewStateData.Id está al final de la línea).

  • El Diseñador de actividad de diagrama de flujo u otros diseñadores de actividad de flujo de trabajo pueden mostrar todos los objetos en sus ubicaciones predeterminadas en lugar de los valores de la propiedad adjunta.

ClickOnce

ClickOnce se ha actualizado para admitir TLS 1.1 y TLS 1.2 además del protocolo 1.0, que ya admite. ClickOnce detecta automáticamente qué protocolo es necesario; no se requieren pasos adicionales en la aplicación ClickOnce para habilitar la compatibilidad con TLS 1.1 y 1.2.

Convertir aplicaciones de Windows Forms y WPF en aplicaciones para UWP

Windows ahora ofrece funcionalidades para incorporar aplicaciones de escritorio de Windows existentes, incluidas las aplicaciones de WPF y Windows Forms, a la Plataforma universal de Windows (UWP). Esta tecnología actúa como puente al permitirle migrar gradualmente la base de código existente a UWP, lo que lleva la aplicación a todos los dispositivos Windows 10.

Las aplicaciones de escritorio convertidas obtienen una identidad de aplicación similar a la identidad de la aplicación de las aplicaciones para UWP, lo que hace que las API de UWP sean accesibles para habilitar características como iconos dinámicos y notificaciones. La aplicación sigue comportándose como antes y se ejecuta como una aplicación de plena confianza. Una vez convertida la aplicación, se puede agregar un proceso de contenedor de aplicaciones al proceso de plena confianza existente para agregar una interfaz de usuario adaptable. Cuando toda la funcionalidad se mueve al proceso del contenedor de la aplicación, se puede eliminar el proceso de confianza total y la nueva aplicación UWP se puede poner a disposición de todos los dispositivos con Windows 10.

Mejoras en la depuración

La API de depuración no administrada se ha mejorado en .NET Framework 4.6.2 para realizar análisis adicionales cuando se lanza un NullReferenceException, de manera que sea posible determinar qué variable en una sola línea de código fuente es null. Para admitir este escenario, se han agregado las API siguientes a la API de depuración no administrada.

Novedades de .NET Framework 4.6.1

.NET Framework 4.6.1 incluye nuevas características en las siguientes áreas:

Para obtener más información sobre .NET Framework 4.6.1, consulte los temas siguientes:

Criptografía: compatibilidad con certificados X509 que contienen ECDSA

.NET Framework 4.6 agregó compatibilidad con RSACng para certificados X509. .NET Framework 4.6.1 agrega compatibilidad con certificados X509 de ECDSA (algoritmo de firma digital de curva elíptica).

ECDSA ofrece un mejor rendimiento y es un algoritmo de criptografía más seguro que RSA, lo que proporciona una excelente opción en la que el rendimiento y la escalabilidad de la capa de transporte (TLS) son un problema. La implementación de .NET Framework encapsula las llamadas a la funcionalidad de Windows existente.

En el código de ejemplo siguiente se muestra lo fácil que es generar una firma para un flujo de bytes mediante la nueva compatibilidad con certificados X509 de ECDSA incluidos en .NET Framework 4.6.1.

using System;
using System.Security.Cryptography;
using System.Security.Cryptography.X509Certificates;

public class Net461Code
{
    public static byte[] SignECDsaSha512(byte[] data, X509Certificate2 cert)
    {
        using (ECDsa privateKey = cert.GetECDsaPrivateKey())
        {
            return privateKey.SignData(data, HashAlgorithmName.SHA512);
        }
    }

    public static byte[] SignECDsaSha512(byte[] data, ECDsa privateKey)
    {
        return privateKey.SignData(data, HashAlgorithmName.SHA512);
    }
}

Imports System.Security.Cryptography
Imports System.Security.Cryptography.X509Certificates

Public Class Net461Code
    Public Shared Function SignECDsaSha512(data As Byte(), cert As X509Certificate2) As Byte()
        Using privateKey As ECDsa = cert.GetECDsaPrivateKey()
            Return privateKey.SignData(data, HashAlgorithmName.SHA512)
        End Using
    End Function

    Public Shared Function SignECDsaSha512(data As Byte, privateKey As ECDsa) As Byte()
        Return privateKey.SignData(data, HashAlgorithmName.SHA512)
    End Function
End Class

Esto ofrece un marcado contraste con el código necesario para generar una firma en .NET Framework 4.6.

using System;
using System.Security.Cryptography;
using System.Security.Cryptography.X509Certificates;

public class Net46Code
{
    public static byte[] SignECDsaSha512(byte[] data, X509Certificate2 cert)
    {
        // This would require using cert.Handle and a series of p/invokes to get at the
        // underlying key, then passing that to a CngKey object, and passing that to
        // new ECDsa(CngKey).  It's a lot of work.
        throw new Exception("That's a lot of work...");
    }

    public static byte[] SignECDsaSha512(byte[] data, ECDsa privateKey)
    {
        // This way works, but SignData probably better matches what you want.
        using (SHA512 hasher = SHA512.Create())
        {
            byte[] signature1 = privateKey.SignHash(hasher.ComputeHash(data));
        }

        // This might not be the ECDsa you got!
        ECDsaCng ecDsaCng = (ECDsaCng)privateKey;
        ecDsaCng.HashAlgorithm = CngAlgorithm.Sha512;
        return ecDsaCng.SignData(data);
    }
}

Imports System.Security.Cryptography
Imports System.Security.Cryptography.X509Certificates

Public Class Net46Code
    Public Shared Function SignECDsaSha512(data As Byte(), cert As X509Certificate2) As Byte()
        ' This would require using cert.Handle and a series of p/invokes to get at the
        ' underlying key, then passing that to a CngKey object, and passing that to
        ' new ECDsa(CngKey).  It's a lot of work.
        Throw New Exception("That's a lot of work...")
    End Function

    Public Shared Function SignECDsaSha512(data As Byte(), privateKey As ECDsa) As Byte()
        ' This way works, but SignData probably better matches what you want.
        Using hasher As SHA512 = SHA512.Create()
            Dim signature1 As Byte() = privateKey.SignHash(hasher.ComputeHash(data))
        End Using

        ' This might not be the ECDsa you got!
        Dim ecDsaCng As ECDsaCng = CType(privateKey, ECDsaCng)
        ecDsaCng.HashAlgorithm = CngAlgorithm.Sha512
        Return ecDsaCng.SignData(data)
    End Function
End Class

ADO.NET

Se han agregado lo siguiente a ADO.NET:

soporte de Always Encrypted para claves protegidas por hardware

ADO.NET ahora admite el almacenamiento de claves maestras de columna de Always Encrypted de forma nativa en módulos de seguridad de hardware (HSM). Con esta compatibilidad, los clientes pueden aprovechar las claves asimétricas almacenadas en HSM sin tener que escribir proveedores personalizados de almacén de claves maestras de columna y registrarlas en aplicaciones.

Los clientes deben instalar el proveedor de CSP proporcionado por el fabricante de HSM o los proveedores de almacén de claves CNG en los servidores de aplicaciones o en los equipos cliente para acceder a los datos de "Always Encrypted" protegidos con las claves maestras de columna que se almacenan en un HSM.

Comportamiento de la conexión de MultiSubnetFailover mejorado para AlwaysOn

SqlClient ahora proporciona automáticamente conexiones más rápidas a un grupo de disponibilidad AlwaysOn (AG). Detecta de forma transparente si la aplicación se conecta a un grupo de disponibilidad AlwaysOn (AG) en una subred diferente y detecta rápidamente el servidor activo actual y proporciona una conexión al servidor. Antes de esta versión, una aplicación tenía que establecer la cadena de conexión para incluir "MultisubnetFailover=true" para indicar que se estaba conectando a un grupo de disponibilidad AlwaysOn. Sin establecer la palabra clave de conexión en true, una aplicación podría experimentar un tiempo de espera al conectarse a un grupo de disponibilidad AlwaysOn. Con esta versión, la aplicación ya no necesita establecer MultiSubnetFailover en true. Para obtener más información sobre la compatibilidad de SqlClient con Always On Availability Groups, consulte Compatibilidad de SqlClient para Alta Disponibilidad y Recuperación ante Desastres.

Windows Presentation Foundation (WPF)

Windows Presentation Foundation incluye varias mejoras y cambios.

Mejora del rendimiento

El retraso en la activación de eventos táctiles se ha corregido en .NET Framework 4.6.1. Además, al escribir un control RichTextBox ya no se bloquea el subproceso de representación durante la entrada rápida.

mejoras de revisión ortográfica

El corrector ortográfico en WPF se ha actualizado en Windows 8.1 y versiones posteriores para aprovechar la compatibilidad del sistema operativo con idiomas adicionales de revisión ortográfica. No hay ningún cambio en la funcionalidad en las versiones de Windows anteriores a Windows 8.1.

Como en versiones anteriores de .NET Framework, el idioma de un control TextBox o un bloque de RichTextBox se detecta buscando información en el orden siguiente:

  • xml:lang, si está presente.

  • Idioma de entrada actual.

  • Cultura actual.

Para obtener más información sobre la compatibilidad con lenguajes en WPF, consulte la entrada de blog WPF en las características de .NET Framework 4.6.1.

Compatibilidad adicional con diccionarios personalizados por usuario

En .NET Framework 4.6.1, WPF reconoce diccionarios personalizados registrados globalmente. Esta funcionalidad está disponible además de la posibilidad de registrarlos por control.

En versiones anteriores de WPF, los diccionarios personalizados no reconoceban las palabras excluidas ni las listas de autocorrección. Se admiten en Windows 8.1 y Windows 10 mediante el uso de archivos que se pueden colocar en el directorio %AppData%\Microsoft\Spelling\<language tag>. Las reglas siguientes se aplican a estos archivos:

  • Los archivos deben tener extensiones de .dic (para palabras agregadas), .exc (para palabras excluidas) o .acl (para Autocorrección).

  • Los archivos deben ser texto sin formato UTF-16 LE que comienza con la marca BOM (Byte Order Mark).

  • Cada línea debe constar de una palabra (en las listas de palabras agregadas y excluidas) o un par de autocorrección con las palabras separadas por una barra vertical ("|") (en la lista de palabras de Autocorrección).

  • Estos archivos se consideran de solo lectura y el sistema no los modifica.

Nota

Estos nuevos formatos de archivo no son compatibles directamente con las API de revisión ortográfica de WPF y los diccionarios personalizados proporcionados a WPF en las aplicaciones deben seguir usando archivos .lex.

Ejemplos

Hay una serie de ejemplos de WPF en el repositorio de GitHub de Microsoft/WPF- Samples. Ayúdanos a mejorar nuestros ejemplos enviando un pull request o creando un problema en GitHub .

extensiones de DirectX

WPF incluye un paquete NuGet que proporciona nuevas implementaciones de D3DImage que facilitan la interoperación con contenido DX10 y Dx11. El código de este paquete se ha abierto y está disponible en GitHub.

Windows Workflow Foundation: Transacciones

El método Transaction.EnlistPromotableSinglePhase ahora puede usar un administrador de transacciones distribuido distinto de MSDTC para promover la transacción. Para ello, especifique un identificador GUID de promoción de transacción para la nueva sobrecarga Transaction.EnlistPromotableSinglePhase(IPromotableSinglePhaseNotification, Guid). Si esta operación se realiza correctamente, existen limitaciones en las funcionalidades de la transacción. Una vez que se activa un promotor de transacciones que no sea MSDTC, los métodos siguientes inician una TransactionPromotionException porque estos métodos requieren promoción a MSDTC:

Una vez que se activa un promotor de transacciones que no sea MSDTC, debe usarse para futuras inscripciones duraderas a través de los protocolos que define. El Guid del promotor de transacción puede obtenerse con la propiedad PromoterType. Cuando se promueve la transacción, el promotor de transacciones proporciona una matriz de Byte que representa el token promocionado. Una aplicación puede obtener el token promocionado para una transacción promocionada que no sea MSDTC con el método GetPromotedToken.

Los usuarios de la nueva sobrecarga Transaction.EnlistPromotableSinglePhase(IPromotableSinglePhaseNotification, Guid) deben seguir una secuencia de llamadas específica para completar correctamente la operación de promoción. Estas reglas se documentan en la documentación del método.

Generación de perfiles

La API de generación de perfiles no administrada se ha mejorado de la siguiente manera:

  • Mejor compatibilidad con el acceso a archivos PDB en la interfaz ICorProfilerInfo7.

    En ASP.NET Core, se está volviendo mucho más común que los ensamblados se compilen en memoria mediante Roslyn. Para los desarrolladores que realizan herramientas de generación de perfiles, esto significa que los archivos PDB que históricamente se serializaron en el disco ya no pueden estar presentes. Las herramientas de perfilado suelen usar PDBs para mapear el código de vuelta a las líneas de origen para tareas como la cobertura de código o el análisis de rendimiento por línea. La interfaz ICorProfilerInfo7 ahora incluye dos nuevos métodos, ICorProfilerInfo7::GetInMemorySymbolsLength y ICorProfilerInfo7::ReadInMemorySymbols, para proporcionar estas herramientas de generador de perfiles con acceso a los datos PDB en memoria, Mediante el uso de las nuevas API, un generador de perfiles puede obtener el contenido de una PDB en memoria como una matriz de bytes y, a continuación, procesarlo o serializarlo en el disco.

  • Mejor instrumentación con la interfaz ICorProfiler.

    Los generadores de perfiles que usan la funcionalidad reJit de las API de ICorProfiler para la instrumentación dinámica ahora pueden modificar algunos metadatos. Anteriormente, estas herramientas podían instrumentar IL en cualquier momento, pero los metadatos solo se podían modificar en tiempo de carga del módulo. Dado que IL hace referencia a metadatos, esto limita los tipos de instrumentación que se pueden realizar. Hemos elevado algunos de esos límites agregando el método ICorProfilerInfo7::ApplyMetaData para admitir un subconjunto de modificaciones de metadatos después de que se cargue el módulo, en particular agregando nuevos registros de AssemblyRef, TypeRef, TypeSpec, MemberRef, MemberSpecy UserString. Este cambio hace posible una gama mucho más amplia de instrumentación sobre la marcha.

PDB del generador de imágenes nativas (NGEN)

El seguimiento de eventos entre máquinas permite a los clientes perfilar un programa en la máquina A y examinar los datos de perfilado con asignación de línea de origen en la máquina B. Con versiones anteriores de .NET Framework, el usuario copiaría todos los módulos e imágenes nativas de la máquina de perfilado a la máquina de análisis que contiene el IL PDB para crear la asignación de origen a nativo. Aunque este proceso puede funcionar bien cuando los archivos son relativamente pequeños, como para las aplicaciones telefónicas, los archivos pueden ser muy grandes en sistemas de escritorio y requieren un tiempo significativo para copiar.

Con los archivos PDB de NGen, NGen puede crear un archivo PDB que contenga la asignación de IL a nativo sin una dependencia del archivo PDB de IL. En nuestro escenario de seguimiento de eventos de varias máquinas, todo lo que se necesita es copiar la imagen nativa PDB generada por la máquina A a la máquina B y utilizar Depurar API de acceso de interfaz para leer la asignación de origen al IL del archivo PDB de IL y la asignación del IL a nativo del archivo PDB de imágenes nativas. La combinación de ambas asignaciones permite asignar código fuente a nativo. Dado que la imagen nativa PDB es mucho más pequeña que todos los módulos e imágenes nativas, el proceso de copia de la máquina A a la máquina B es mucho más rápido.

Novedades de .NET 2015

.NET 2015 presenta .NET Framework 4.6 y .NET Core. Algunas características nuevas se aplican a ambos, y otras características son específicas de .NET Framework 4.6 o .NET Core.

  • ASP.NET Core

    .NET 2015 incluye ASP.NET Core, que es una implementación de .NET ajustada para crear aplicaciones modernas basadas en la nube. ASP.NET Core es modular, por lo que solo puede incluir las características necesarias en la aplicación. Se puede hospedar en IIS o autohospedado en un proceso personalizado, y puede ejecutar aplicaciones con diferentes versiones de .NET Framework en el mismo servidor. Incluye un nuevo sistema de configuración de entorno diseñado para la implementación en la nube.

    MVC, WEB API y Web Pages se unifican en un único marco denominado MVC 6. Las aplicaciones de ASP.NET Core se compilan a través de herramientas en Visual Studio 2015 o posterior. Las aplicaciones existentes funcionarán en el nuevo .NET Framework; sin embargo, para compilar una aplicación que use MVC 6 o SignalR 3, debe usar el sistema de proyecto en Visual Studio 2015 o posterior.

    Para obtener información, consulte ASP.NET Core.

  • Actualizaciones de ASP.NET

    • API basada en tareas para el vaciado de respuestas asincrónicas

      ASP.NET ahora proporciona una API sencilla basada en tareas para el vaciado de respuesta asincrónica, HttpResponse.FlushAsync, que permite vaciar las respuestas de forma asincrónica usando el soporte de async/await de su lenguaje.

    • El enlace de modelos admite los métodos de devolución de tareas

      En .NET Framework 4.5, ASP.NET añadió la funcionalidad de enlace de modelos que habilitó un enfoque extensible enfocado en el código para las operaciones de datos basadas en CRUD en páginas Web Forms y controles de usuario. El sistema de enlace de modelos ahora admite métodos de enlace de modelos que devuelven Task. Esta característica permite a los desarrolladores de Web Forms obtener las ventajas de escalabilidad de async con la facilidad del sistema de enlace de datos al usar versiones más recientes de ORM, incluido Entity Framework.

      El enlace de modelos asincrónicos se controla mediante el ajuste de configuración aspnet:EnableAsyncModelBinding.

      <appSettings>
    <add key=" aspnet:EnableAsyncModelBinding" value="true|false" />
</appSettings>

      En las aplicaciones dirigidas a .NET Framework 4.6, el valor predeterminado es true. En las aplicaciones que se ejecutan en .NET Framework 4.6 y que tienen como destino una versión anterior de .NET Framework, se establece en false de forma predeterminada. Se puede habilitar estableciendo el valor de configuración en true.

    • compatibilidad con HTTP/2 (Windows 10)

      HTTP/2 es una nueva versión del protocolo HTTP que proporciona un uso de conexión mucho mejor (menos recorridos de ida y vuelta entre el cliente y el servidor), lo que da lugar a una menor carga de páginas web de latencia para los usuarios. Las páginas web (en lugar de los servicios) se benefician más de HTTP/2, ya que el protocolo optimiza para varios artefactos que se solicitan como parte de una sola experiencia. Se ha agregado compatibilidad con HTTP/2 a ASP.NET en .NET Framework 4.6. Dado que la funcionalidad de red existe en varias capas, se requerían nuevas características en Windows, en IIS y en ASP.NET para habilitar HTTP/2. Debe ejecutarse en Windows 10 para usar HTTP/2 con ASP.NET.

      HTTP/2 también se admite y está activado por defecto para las aplicaciones de la Plataforma Universal de Windows (UWP) de Windows 10 que usan la API System.Net.Http.HttpClient.

      Para proporcionar una manera de usar la característica PUSH_PROMISE en ASP.NET aplicaciones, se ha agregado un nuevo método con dos sobrecargas, PushPromise(String) y PushPromise(String, String, NameValueCollection), a la clase HttpResponse.

      Nota

      Aunque ASP.NET Core admite HTTP/2, aún no se ha agregado compatibilidad con la característica PUSH PROMISE.

      El explorador y el servidor web (IIS en Windows) realizan todo el trabajo. No tiene que hacer el trabajo más farragoso para los usuarios.

      La mayoría de los principales exploradores admiten HTTP/2, por lo que es probable que los usuarios se beneficien de la compatibilidad con HTTP/2 si el servidor lo admite.

    • Compatibilidad con el Token Binding Protocol

      Microsoft y Google han estado colaborando en un nuevo enfoque de autenticación, denominado protocolo de enlace de tokens . La premisa es que los tokens de autenticación (en la caché de su navegador) pueden ser robados y utilizados por criminales para acceder a recursos seguros (por ejemplo, su cuenta bancaria) sin necesitar su contraseña ni cualquier otro conocimiento privilegiado. El nuevo protocolo tiene como objetivo mitigar este problema.

      El protocolo de enlace de tokens se implementará en Windows 10 como característica del explorador. ASP.NET aplicaciones participarán en el protocolo para que los tokens de autenticación se validen como legítimos. El cliente y las implementaciones del servidor establecen la protección de un extremo a otro especificada por el protocolo.

    • Algoritmos hash de cadena aleatoria

      .NET Framework 4.5 introdujo un algoritmo hash de cadena aleatorio . Sin embargo, no fue compatible con ASP.NET debido a que algunas características de ASP.NET dependían de un código hash estable. En .NET Framework 4.6, ahora se admiten algoritmos hash de cadena aleatorios. Para habilitar esta característica, use la configuración de aspnet:UseRandomizedStringHashAlgorithm.

      <appSettings>
    <add key="aspnet:UseRandomizedStringHashAlgorithm" value="true|false" />
</appSettings>

  • ADO.NET

    ADO .NET ahora admite la característica Always Encrypted disponible en SQL Server 2016. Con Always Encrypted, SQL Server puede realizar operaciones en datos cifrados, y lo mejor de toda la clave de cifrado reside con la aplicación dentro del entorno de confianza del cliente y no en el servidor. Always Encrypted protege los datos de los clientes para que los DBA no tengan acceso a datos de texto sin formato. El cifrado y el descifrado de datos se producen de forma transparente en el nivel de controlador, lo que minimiza los cambios que se deben realizar en las aplicaciones existentes. Para obtener más información, consulte Always Encrypted (motor de base de datos) y Always Encrypted (desarrollo de cliente).

  • compilador JIT de 64 bits para código administrado

    .NET Framework 4.6 incluye una nueva versión del compilador JIT de 64 bits (originalmente denominado RyuJIT). El nuevo compilador de 64 bits proporciona mejoras de rendimiento significativas en el compilador JIT de 64 bits anterior. El nuevo compilador de 64 bits está habilitado para procesos de 64 bits que se ejecutan sobre .NET Framework 4.6. La aplicación se ejecutará en un proceso de 64 bits si se compila como 64 bits o AnyCPU y se ejecuta en un sistema operativo de 64 bits. Aunque se ha tomado cuidado para realizar la transición al nuevo compilador lo más transparente posible, se pueden realizar cambios en el comportamiento.

    El nuevo compilador JIT de 64 bits también incluye características de aceleración SIMD de hardware cuando se combina con tipos habilitados para SIMD en el espacio de nombres System.Numerics, lo que puede producir buenas mejoras de rendimiento.

  • Mejoras en el cargador de ensamblados

    Ahora el cargador de ensamblados usa la memoria de un modo más eficaz al descargar ensamblados de IL después de cargar una imagen NGEN correspondiente. Este cambio reduce la memoria virtual, lo que es especialmente beneficioso para aplicaciones de 32 bits grandes (como Visual Studio) y también guarda memoria física.

  • Cambios en la Biblioteca de Clases Base

    Se han agregado muchas API nuevas a .NET Framework 4.6 para habilitar escenarios clave. Estos incluyen los siguientes cambios y adiciones:

    • Implementaciones de IReadOnlyCollection<T>

      Las colecciones adicionales implementan IReadOnlyCollection<T>, tales como Queue<T> y Stack<T>.

    • CultureInfo.CurrentCulture y CultureInfo.CurrentUICulture

      Las propiedades CultureInfo.CurrentCulture y CultureInfo.CurrentUICulture ahora son de lectura y escritura, en lugar de solo lectura. Si asigna un nuevo objeto CultureInfo a estas propiedades, la referencia cultural del subproceso actual definida por la propiedad Thread.CurrentThread.CurrentCulture y la referencia cultural del subproceso de interfaz de usuario actual definida por las propiedades de Thread.CurrentThread.CurrentUICulture también cambian.

    • Mejoras en la recolección de basura (GC)

      La clase GC ahora incluye los métodos TryStartNoGCRegion y EndNoGCRegion que permiten impedir la recolección de basura durante la ejecución de un camino crítico.

      Una nueva sobrecarga del método GC.Collect(Int32, GCCollectionMode, Boolean, Boolean) permite controlar si el montón del objeto pequeño y el montón del objeto grande se exploran y compactan o si solo se exploran.

    • Tipos habilitados para SIMD

      El espacio de nombres System.Numerics ahora incluye varios tipos habilitados para SIMD, como Matrix3x2, Matrix4x4, Plane, Quaternion, Vector2, Vector3y Vector4.

      Dado que el nuevo compilador JIT de 64 bits también incluye características de aceleración SIMD de hardware, hay mejoras de rendimiento especialmente significativas al usar los tipos habilitados para SIMD con el nuevo compilador JIT de 64 bits.

    • Actualizaciones de criptografía

      La API System.Security.Cryptography se está actualizando para que sea compatible con las API de criptografía CNG de Windows. Las versiones anteriores de .NET Framework dependían totalmente de una versión anterior de las API de criptografía de Windows como base para la implementación de System.Security.Cryptography. Hemos tenido solicitudes para admitir la API de CNG, ya que admite algoritmos de criptografía modernos, que son importantes para determinadas categorías de aplicaciones.

      .NET Framework 4.6 incluye las siguientes mejoras nuevas para admitir las API de criptografía de CNG de Windows:

      • Conjunto de métodos de extensión para certificados X509, System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPublicKey(System.Security.Cryptography.X509Certificates.X509Certificate2) y System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPrivateKey(System.Security.Cryptography.X509Certificates.X509Certificate2), que devuelven una implementación basada en CNG en lugar de una implementación basada en CAPI siempre que sea posible. (algunas tarjetas inteligentes, entre otros, siguen necesitando CAPI, mientras que las API controlan la reserva).

      • La clase System.Security.Cryptography.RSACng, que proporciona una implementación de CNG del algoritmo RSA.

      • Mejoras en la API de RSA, de modo que las acciones habituales ya no necesitan ninguna conversión. Por ejemplo, el cifrado de datos mediante un objeto X509Certificate2 requiere código como el siguiente en versiones anteriores de .NET Framework.

        RSACryptoServiceProvider rsa = (RSACryptoServiceProvider)cert.PrivateKey;
byte[] oaepEncrypted = rsa.Encrypt(data, true);
byte[] pkcs1Encrypted = rsa.Encrypt(data, false);

        Dim rsa As RSACryptoServiceProvider = CType(cert.PrivateKey, RSACryptoServiceProvider)
Dim oaepEncrypted() As Byte = rsa.Encrypt(data, True)
Dim pkcs1Encrypted() As Byte = rsa.Encrypt(data, False)

        El código que usa las nuevas API de criptografía de .NET Framework 4.6 se puede reescribir del siguiente modo para evitar la conversión.

        RSA rsa = cert.GetRSAPrivateKey();
if (rsa == null)
   throw new InvalidOperationException("An RSA certificate was expected");

byte[] oaepEncrypted = rsa.Encrypt(data, RSAEncryptionPadding.OaepSHA1);
byte[] pkcs1Encrypted = rsa.Encrypt(data, RSAEncryptionPadding.Pkcs1);

        Dim rsa As RSA = cert.GetRSAPrivateKey()
If rsa Is Nothing Then
    Throw New InvalidOperationException("An RSA certificate was expected")
End If

Dim oaepEncrypted() As Byte = rsa.Encrypt(data, RSAEncryptionPadding.OaepSHA1)
Dim pkcs1Encrypted() As Byte = rsa.Encrypt(data, RSAEncryptionPadding.Pkcs1)

    • Compatibilidad con la conversión de fechas y horas a o desde la hora de Unix

      Se han agregado los siguientes métodos nuevos a la estructura DateTimeOffset para admitir la conversión de valores de fecha y hora a o desde la hora de Unix:

    • Interruptores de compatibilidad

      La clase AppContext añade una nueva característica de compatibilidad que permite a los desarrolladores de bibliotecas proporcionar un mecanismo uniforme de exclusión para la nueva funcionalidad destinada a sus usuarios. Establece un contrato de acoplamiento flexible entre componentes para comunicar una solicitud de exclusión. Esta funcionalidad suele ser importante cuando se realiza un cambio en la funcionalidad existente. Por el contrario, ya hay un consentimiento implícito para la nueva funcionalidad.

      Con AppContext, las bibliotecas definen y exponen modificadores de compatibilidad, mientras que el código que depende de ellos puede establecer esos modificadores para que afecten al comportamiento de la biblioteca. De forma predeterminada, las bibliotecas proporcionan la nueva funcionalidad y solo la modifican (es decir, proporcionan la funcionalidad anterior) si se establece el interruptor.

      Una aplicación (o una biblioteca) puede declarar el valor de un switch (que siempre es un valor Boolean) que define una biblioteca dependiente. El modificador siempre es implícitamente false. Al configurar el interruptor en true, se habilita. Establecer explícitamente el interruptor en false proporciona el nuevo comportamiento.

      AppContext.SetSwitch("Switch.AmazingLib.ThrowOnException", true);

      AppContext.SetSwitch("Switch.AmazingLib.ThrowOnException", True)

      La biblioteca debe comprobar si un consumidor ha declarado el valor del interruptor y, a continuación, actuar en consecuencia.

      if (!AppContext.TryGetSwitch("Switch.AmazingLib.ThrowOnException", out shouldThrow))
{
    // This is the case where the switch value was not set by the application.
    // The library can choose to get the value of shouldThrow by other means.
    // If no overrides nor default values are specified, the value should be 'false'.
    // A false value implies the latest behavior.
}

// The library can use the value of shouldThrow to throw exceptions or not.
if (shouldThrow)
{
    // old code
}
else
{
    // new code
}

      If Not AppContext.TryGetSwitch("Switch.AmazingLib.ThrowOnException", shouldThrow) Then
    ' This is the case where the switch value was not set by the application.
    ' The library can choose to get the value of shouldThrow by other means.
    ' If no overrides nor default values are specified, the value should be 'false'.
    ' A false value implies the latest behavior.
End If

' The library can use the value of shouldThrow to throw exceptions or not.
If shouldThrow Then
    ' old code
Else
    ' new code
End If

      Es beneficioso usar un formato coherente para los interruptores, ya que son un contrato formal expuesto por una biblioteca. A continuación se muestran dos formatos obvios.

      • Modificador.espacio de nombres.nombre del modificador

      • Modificador.biblioteca.nombre del modificador

    • Cambios en el patrón asincrónico basado en tareas (TAP)

      Para las aplicaciones que tienen como destino .NET Framework 4.6, los objetos Task y Task<TResult> heredan la referencia cultural y la referencia cultural de interfaz de usuario del subproceso que realiza la llamada. El comportamiento de las aplicaciones destinadas a versiones anteriores de .NET Framework o que no tienen como destino una versión específica de .NET Framework no se ve afectada. Para obtener más información, vea la sección "Cultura y operaciones asincrónicas basadas en tareas" del tema de la clase CultureInfo.

      La clase System.Threading.AsyncLocal<T> permite representar datos ambientales locales a un flujo de control asincrónico determinado, como un método async. Se puede usar para conservar los datos entre subprocesos. También puede definir un método de devolución de llamada que se le notifique al cambiar los datos de ambiente, ya sea porque se ha cambiado la propiedad AsyncLocal<T>.Value de forma explícita o porque el subproceso ha encontrado una transición de contexto.

      Se han agregado tres métodos útiles, Task.CompletedTask, Task.FromCanceledy Task.FromException, al patrón asincrónico basado en tareas (TAP) para devolver tareas completadas en un estado determinado.

      La clase NamedPipeClientStream ahora admite la comunicación asincrónica con su nueva ConnectAsync. .

    • EventSource ahora admite la escritura en el registro de eventos

      Ahora puede usar la clase EventSource para registrar mensajes administrativos o operativos en el registro de eventos, además de las sesiones ETW existentes creadas en la máquina. En el pasado, necesitabas usar el paquete NuGet de Microsoft.Diagnostics.Tracing.EventSource para esta funcionalidad. Esta funcionalidad ahora está integrada en .NET Framework 4.6.

      Tanto el paquete NuGet como .NET Framework 4.6 se han actualizado con las siguientes características:

      • eventos dinámicos

        Permite eventos definidos "sobre la marcha" sin crear métodos de evento.

      • Cargas enriquecidas

        Permite pasar clases y arreglos con atributos especiales, así como tipos primitivos como carga útil.

      • Seguimiento de actividad

        Hace que los eventos Start y Stop etiqueten los eventos entre ellos con un identificador que represente todas las actividades activas actualmente.

      Para admitir estas características, se ha agregado el método Write sobrecargado a la clase EventSource.

  • Windows Presentation Foundation (WPF)

    • Mejoras de HDPI

      La compatibilidad con HDPI en WPF ahora es mejor en .NET Framework 4.6. Se han hecho cambios en el redondeo del diseño para reducir las instancias de recorte en los controles que contienen bordes. De forma predeterminada, esta característica solo está habilitada si el TargetFrameworkAttribute está establecido en .NET Framework 4.6. Las aplicaciones que tienen como destino versiones anteriores del marco, pero que se ejecutan en .NET Framework 4.6 pueden participar en el nuevo comportamiento agregando la línea siguiente a la sección del entorno de ejecución de del archivo de app.config:

      <AppContextSwitchOverrides
value="Switch.MS.Internal.DoNotApplyLayoutRoundingToMarginsAndBorderThickness=false"
/>

      Actualmente, las ventanas de WPF que ocupan varios monitores con diferentes valores de PPP (configuración de varios PPP) se representan completamente sin regiones oscurecidas. Para desactivar este comportamiento, agregue la siguiente línea a la sección <appSettings> del archivo app.config para deshabilitar este nuevo comportamiento:

      <add key="EnableMultiMonitorDisplayClipping" value="true"/>

      Se ha agregado a System.Windows.Input.Cursor compatibilidad para cargar automáticamente el cursor adecuado según la configuración de PPP.

    • Mejor si es táctil

      Los informes de los clientes en Connect acerca del comportamiento impredecible de la función táctil se han tratado en .NET Framework 4.6. Ahora, el umbral de doble punteo de las aplicaciones de WPF y de la Tienda Windows es el mismo en Windows 8.1 y versiones superiores.

    • Compatibilidad con las ventanas secundarias transparentes

      WPF en .NET Framework 4.6 admite ventanas secundarias transparentes en Windows 8.1 y versiones posteriores. de manera que puede crear ventanas secundarias transparentes y no rectangulares en las ventanas de nivel superior. Puede habilitar esta característica estableciendo la propiedad HwndSourceParameters.UsesPerPixelTransparency en true.

  • Windows Communication Foundation (WCF)

    • compatibilidad con SSL

      WCF ahora admite la versión SSL TLS 1.1 y TLS 1.2, además de SSL 3.0 y TLS 1.0, al usar NetTcp con seguridad de transporte y autenticación de cliente. Ahora es posible seleccionar qué protocolo usar o deshabilitar los protocolos menos seguros antiguos. Esto se puede hacer estableciendo la propiedad SslProtocols o agregando lo siguiente a un archivo de configuración.

      <netTcpBinding>
    <binding>
      <security mode= "None|Transport|Message|TransportWithMessageCredential" >
          <transport clientCredentialType="None|Windows|Certificate"
                    protectionLevel="None|Sign|EncryptAndSign"
                    sslProtocols="Ssl3|Tls1|Tls11|Tls12">
            </transport>
      </security>
    </binding>
</netTcpBinding>

    • Enviar mensajes mediante diferentes conexiones HTTP

      WCF ahora permite a los usuarios asegurarse de que determinados mensajes se envían mediante diferentes conexiones HTTP subyacentes. Hay dos maneras de hacerlo:

      • Usar un prefijo de nombre de grupo de conexiones

        Los usuarios pueden especificar una cadena que WCF usará como prefijo para el nombre del grupo de conexiones. Se envían dos mensajes con prefijos diferentes mediante diferentes conexiones HTTP subyacentes. Para establecer el prefijo, agregue un par clave-valor a la propiedad Message.Properties del mensaje. La clave es "HttpTransportConnectionGroupNamePrefix"; el valor es el prefijo deseado.

      • Uso de diferentes generadores de canales

        Los usuarios también pueden habilitar una característica que garantiza que los mensajes enviados mediante canales creados por diferentes generadores de canales usarán diferentes conexiones HTTP subyacentes. Para habilitar esta característica, los usuarios deben cambiar de appSetting a true.

        <appSettings>
    <add key="wcf:httpTransportBinding:useUniqueConnectionPoolPerFactory" value="true" />
</appSettings>

  • Windows Workflow Foundation (WWF)

    Ahora puede especificar los segundos durante los que un servicio de flujo de trabajo retendrá una solicitud de operación fuera de servicio cuando haya un marcador que no sea de protocolo pendiente antes de que expire la solicitud. Un marcador "no de protocolo" es un marcador que no está relacionado con las actividades de recepción pendientes. Algunas actividades crean marcadores que no son protocolos dentro de su implementación, por lo que es posible que no sea obvio que existe un marcador que no sea de protocolo. Entre ellas se encuentran Estado y Selección. Si tiene un servicio de flujo de trabajo implementado con un equipo de estado o que contiene una actividad de selección, lo más probable es que tenga marcadores no de protocolo. Para especificar el intervalo, agregue una línea como la siguiente a la sección appSettings del archivo app.config:

    <add key="microsoft:WorkflowServices:FilterResumeTimeoutInSeconds" value="60"/>

    El valor predeterminado es 60 segundos. Si value se establece en 0, las solicitudes desordenadas se rechazan inmediatamente con un error con texto similar al siguiente:

    Operation 'Request3|{http://tempuri.org/}IService' on service instance with identifier '2b0667b6-09c8-4093-9d02-f6c67d534292' cannot be performed at this time. Please ensure that the operations are performed in the correct order and that the binding in use provides ordered delivery guarantees.

    Este es el mismo mensaje que aparece si recibe un mensaje de operación fuera de servicio y no hay ningún marcador que no sea de protocolo.

    Si el valor del elemento FilterResumeTimeoutInSeconds es distinto de cero, hay marcadores que no son de protocolo y el intervalo de tiempo de espera expira, se produce un error en la operación con un mensaje de tiempo de espera.

  • Transacciones

    Ahora puede incluir el identificador de transacción distribuida para la transacción que provocó que se produjera una excepción derivada de TransactionException. Para ello, agregue la siguiente clave a la sección appSettings del archivo app.config:

    <add key="Transactions:IncludeDistributedTransactionIdInExceptionMessage" value="true"/>

    El valor predeterminado es false.

  • Redes

    • Reutilización del socket

      Windows 10 incluye un nuevo algoritmo de red de alta escalabilidad que hace un mejor uso de los recursos de la máquina mediante la reutilización de puertos locales para las conexiones TCP salientes. .NET Framework 4.6 admite el nuevo algoritmo, lo que permite que las aplicaciones .NET aprovechen el nuevo comportamiento. En versiones anteriores de Windows, había un límite de conexión simultáneo artificial (normalmente 16 384, el tamaño predeterminado del intervalo de puertos dinámico), que podría limitar la escalabilidad de un servicio al provocar agotamiento del puerto cuando se está cargando.

      En .NET Framework 4.6, se han agregado dos API para habilitar la reutilización del puerto, lo que elimina eficazmente el límite de 64 KB en conexiones simultáneas:

      De forma predeterminada, la propiedad ServicePointManager.ReusePort es false, a menos que el valor HWRPortReuseOnSocketBind de la clave del Registro HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 se establezca en 0x1. Para habilitar la reutilización del puerto local en conexiones HTTP, establezca la propiedad ServicePointManager.ReusePort en true. Esto hace que todas las conexiones de socket TCP salientes de HttpClient y HttpWebRequest usen una nueva opción de socket de Windows 10, SO_REUSE_UNICASTPORT, que habilita la reutilización del puerto local.

      Los desarrolladores que crean una aplicación solo de sockets pueden especificar la opción System.Net.Sockets.SocketOptionName al llamar a un método (como Socket.SetSocketOption) para que los sockets de salida reutilicen los puertos locales durante el enlace.

    • Compatibilidad con nombres de dominio internacionales y Punycode

      Se ha agregado una nueva propiedad, IdnHost, a la clase Uri para admitir mejor nombres de dominio internacionales y PunyCode.

  • Cambio de tamaño en controles de Windows Forms

    Esta característica se ha ampliado en .NET Framework 4.6 para incluir los tipos DomainUpDown, NumericUpDown, DataGridViewComboBoxColumn, DataGridViewColumn y ToolStripSplitButton y el rectángulo especificado por la propiedad Bounds que se usa al dibujar un UITypeEditor.

    Se trata de una característica opcional. Para habilitarlo, establezca el elemento EnableWindowsFormsHighDpiAutoResizing en true en el archivo de configuración de la aplicación (app.config):

    <appSettings>
    <add key="EnableWindowsFormsHighDpiAutoResizing" value="true" />
</appSettings>

  • Compatibilidad para codificaciones de páginas de códigos

    .NET Core admite principalmente las codificaciones Unicode y, de forma predeterminada, proporciona compatibilidad limitada con codificaciones de página de códigos. Puede agregar compatibilidad con codificaciones de página de códigos disponibles en .NET Framework, pero no compatibles en .NET Core mediante el registro de codificaciones de página de códigos con el método Encoding.RegisterProvider. Para obtener más información, consulte System.Text.CodePagesEncodingProvider.

  • .NET Native

Las aplicaciones de la Plataforma universal de Windows (UWP) escritas en C# o Visual Basic pueden aprovechar una nueva tecnología que compila aplicaciones en código nativo en lugar de IL. Esta tecnología genera aplicaciones que tienen tiempos de inicio y ejecución más rápidos. Para obtener más información, consulte Compilación de aplicaciones con .NET Native. Para obtener información general sobre .NET Native que examina cómo difiere de la compilación JIT y NGEN y lo que significa para el código, consulte .NET Native and Compilation.

Las aplicaciones se compilan en código nativo de forma predeterminada al compilarlas con Visual Studio 2015 o posterior. Para obtener más información, consulte "Comenzar con .NET Native" .

Para admitir la depuración de aplicaciones nativas de .NET, se han agregado varias interfaces y enumeraciones nuevas a la API de depuración no administrada. Para obtener más información, consulte el tema Depuración (Referencia de la API no administrada).

  • Paquetes de código abierto de .NET Framework

    Los paquetes de .NET Core, como las colecciones inmutables, las API de SIMD y las API de red, como las que se encuentran en el espacio de nombres de System.Net.Http, ahora están disponibles como paquetes de código abierto en GitHub. Para acceder al código, consulte .NET en GitHub. Para obtener más información y cómo contribuir a estos paquetes, consulte Introducción a .NET, página principal de .NET en GitHub.

Novedades de .NET Framework 4.5.2

  • Nuevas API para aplicaciones de ASP.NET. Los nuevos métodos HttpResponse.AddOnSendingHeaders y HttpResponseBase.AddOnSendingHeaders permiten inspeccionar y modificar las cabeceras de respuesta y el código de estado a medida que la respuesta se transmite a la aplicación cliente. Considere la posibilidad de usar estos métodos en lugar de los eventos de PreSendRequestHeaders y PreSendRequestContent; son más eficientes y confiables.

    El método HostingEnvironment.QueueBackgroundWorkItem permite programar pequeños elementos de trabajo en segundo plano. ASP.NET realiza un seguimiento de estos elementos e impide que IIS termine abruptamente el proceso de trabajo hasta que se hayan completado todos los elementos de trabajo en segundo plano. No se puede llamar a este método fuera de un dominio de aplicación administrada ASP.NET.

    Las nuevas propiedades HttpResponse.HeadersWritten y HttpResponseBase.HeadersWritten devuelven valores booleanos que indican si se han escrito los encabezados de respuesta. Puede usar estas propiedades para asegurarse de que las llamadas a las API, como HttpResponse.StatusCode (que producen excepciones si se han escrito los encabezados) se realizarán correctamente.

  • Redimensionamiento en los controles de formularios de Windows Forms. Esta característica se ha ampliado. Ahora puede utilizar la configuración de DPI del sistema para redimensionar los componentes de los controles adicionales, como la flecha desplegable en cuadros combinados.

    Se trata de una característica de activación opcional. Para habilitarlo, establezca el elemento EnableWindowsFormsHighDpiAutoResizing en true en el archivo de configuración de la aplicación (app.config):

    <appSettings>
    <add key="EnableWindowsFormsHighDpiAutoResizing" value="true" />
</appSettings>

  • Nueva característica de flujo de trabajo. Un administrador de recursos que usa el método EnlistPromotableSinglePhase (y, por tanto, la implementación de la interfaz IPromotableSinglePhaseNotification) puede usar el nuevo método Transaction.PromoteAndEnlistDurable para solicitar lo siguiente:

    Esto se puede hacer dentro del mismo dominio de aplicación y no requiere ningún código no administrado adicional para interactuar con MSDTC para realizar la promoción. Solo se puede llamar al nuevo método cuando existe una llamada pendiente de System.Transactions al método IPromotableSinglePhaseNotificationPromote que está implementado por una inscripción que puede promocionarse.

  • Mejoras de generación de perfiles. Las siguientes NUEVAS API de generación de perfiles no administradas proporcionan una generación de perfiles más sólida:

    Las implementaciones de ICorProfiler anteriores eran compatibles con la carga diferida de ensamblados dependientes. Las nuevas API de generación de perfiles requieren que los ensamblados dependientes insertados por el generador de perfiles se puedan cargar inmediatamente, en lugar de cargarse después de inicializar completamente la aplicación. Este cambio no afecta a los usuarios de las API de ICorProfiler existentes.

  • Mejoras en la depuración. Las siguientes NUEVAS API de depuración no administradas proporcionan una mejor integración con un generador de perfiles. Ahora se puede acceder a metadatos insertados por el generador de perfiles, así como a variables locales y código producidos por solicitudes de ReJIT del compilador en la depuración de volcados.

  • Cambios en el seguimiento de eventos. .NET Framework 4.5.2 habilita el seguimiento de actividades basado en el seguimiento de eventos para Windows (ETW) fuera del proceso para una mayor área de cobertura. Esto permite a los proveedores de Administración avanzada de energía (APM) proporcionar herramientas ligeras que realicen un seguimiento preciso de los costos de las solicitudes y actividades individuales que cruzan subprocesos. Estos eventos solo se generan cuando los controladores ETW los habilitan; por lo tanto, los cambios no afectan al código ETW escrito previamente o al código que se ejecuta con ETW deshabilitado.

  • Promover una transacción y convertirla en una inscripción duradera

    Transaction.PromoteAndEnlistDurable es una nueva API agregada a .NET Framework 4.5.2 y 4.6:

    [System.Security.Permissions.PermissionSetAttribute(System.Security.Permissions.SecurityAction.LinkDemand, Name = "FullTrust")]
public Enlistment PromoteAndEnlistDurable(Guid resourceManagerIdentifier,
                                          IPromotableSinglePhaseNotification promotableNotification,
                                          ISinglePhaseNotification enlistmentNotification,
                                          EnlistmentOptions enlistmentOptions)

    <System.Security.Permissions.PermissionSetAttribute(System.Security.Permissions.SecurityAction.LinkDemand, Name:="FullTrust")>
public Function PromoteAndEnlistDurable(resourceManagerIdentifier As Guid,
                                        promotableNotification As IPromotableSinglePhaseNotification,
                                        enlistmentNotification As ISinglePhaseNotification,
                                        enlistmentOptions As EnlistmentOptions) As Enlistment

    El método se puede usar con una inscripción creada previamente por Transaction.EnlistPromotableSinglePhase en respuesta al método ITransactionPromoter.Promote. Pide a System.Transactions que promueva la transacción a una transacción MSDTC y que "convierta" la inscripción que se puede promover en una inscripción duradera. Una vez completado correctamente este método, la interfaz IPromotableSinglePhaseNotification ya no será referenciada por System.Transactionsy las notificaciones futuras llegarán a la interfaz ISinglePhaseNotification proporcionada. La inscripción en cuestión debe actuar como una inscripción duradera, lo que admite el registro de transacciones y la recuperación. Consulte Transaction.EnlistDurable para obtener más información. Además, la inscripción debe admitir ISinglePhaseNotification. Solo se puede llamar a este método al procesar una llamada de ITransactionPromoter.Promote. Si no es el caso, se produce una excepción TransactionException.

Novedades de .NET Framework 4.5.1

Actualizaciones de abril de 2014:

  • visual Studio 2013 Update 2 incluye actualizaciones de las plantillas de biblioteca de clases portables para admitir estos escenarios:

    • Puedes usar las API de Windows Runtime en bibliotecas portátiles destinadas a Windows 8.1, Windows Phone 8.1 y Windows Phone Silverlight 8.1.

    • Puedes incluir XAML (tipos Windows.UI.XAML) en bibliotecas portátiles cuando tengas como destino Windows 8.1 o Windows Phone 8.1. Se admiten las siguientes plantillas XAML: Página en blanco, Diccionario de recursos, Control con plantilla y Control de usuario.

    • Puedes crear un componente portátil de Windows Runtime (archivo .winmd) para usarlo en aplicaciones de la Tienda destinadas a Windows 8.1 y Windows Phone 8.1.

    • Puede cambiar el destino de una biblioteca de clases de la Tienda Windows o la Tienda de Windows Phone como biblioteca de clases portable.

    Para obtener más información sobre estos cambios, vea Biblioteca de clases portable.

  • El conjunto de contenido de .NET Framework ahora incluye documentación para .NET Native, que es una tecnología de precompilación para compilar e implementar aplicaciones de Windows. .NET Native compila las aplicaciones directamente en código nativo, en lugar de en lenguaje intermedio (IL) para mejorar el rendimiento. Para obtener más información, consulte Compilación de aplicaciones con .NET Native.

  • La fuente de referencia de .NET Framework proporciona una nueva experiencia de navegación y mejor funcionalidad. Ahora puede navegar en línea por el código fuente de .NET Framework, descargar la referencia para visualizarlo sin conexión y examinar los orígenes (incluidas revisiones y actualizaciones) durante la depuración. Para obtener más información, consulte la entrada de blog Una nueva apariencia para la fuente de referencia de .NET.

Entre las nuevas características y mejoras de las clases base de .NET Framework 4.5.1 se incluyen:

  • Redirección automática de enlace de ensamblados. A partir de Visual Studio 2013, al compilar una aplicación destinada a .NET Framework 4.5.1, se pueden agregar redirecciones de enlace al archivo de configuración de la aplicación si la aplicación o sus componentes hacen referencia a varias versiones del mismo ensamblado. También puede habilitar esta característica para proyectos que tienen como destino versiones anteriores de .NET Framework. Para obtener más información, vea Cómo: Habilitar y deshabilitar redireccionamiento de enlaces automático.

  • Capacidad de recopilar información de diagnóstico para ayudar a los desarrolladores a mejorar el rendimiento de las aplicaciones en la nube y del servidor. Para obtener más información, vea los métodos WriteEventWithRelatedActivityId y WriteEventWithRelatedActivityIdCore en la clase EventSource.

  • Capacidad de compactar explícitamente el montón de objetos grandes (LOH) durante la recolección de basura. Para obtener más información, vea la propiedad GCSettings.LargeObjectHeapCompactionMode.

  • Mejoras de rendimiento adicionales, como la suspensión de aplicaciones en ASP.NET, mejoras en el JIT para múltiples núcleos, y un inicio de aplicaciones más rápido después de una actualización de .NET Framework. Para obtener más información, consulte el anuncio de .NET Framework 4.5.1 y la entrada de blog sobre la suspensión de aplicaciones ASP.NET .

Entre las mejoras de Windows Forms se incluyen las siguientes:

  • Cambio de tamaño en controles de Windows Forms. Puede usar el valor de PPP del sistema para cambiar el tamaño de los componentes de controles (por ejemplo, los iconos que aparecen en una cuadrícula de propiedades); para ello, active esta opción con una entrada en el archivo de configuración de la aplicación (app.config). Esta característica se admite actualmente en los siguientes controles de Windows Forms:

    Para habilitar esta característica, agregue un nuevo elemento <appSettings> al archivo de configuración (app.config) y establezca el elemento EnableWindowsFormsHighDpiAutoResizing en true:

    <appSettings>
    <add key="EnableWindowsFormsHighDpiAutoResizing" value="true" />
</appSettings>

Entre las mejoras al depurar tus aplicaciones de .NET Framework en Visual Studio 2013 se incluyen:

  • Devuelve valores en el depurador de Visual Studio. Al depurar una aplicación administrada en Visual Studio 2013, la ventana Autos muestra los tipos y valores devueltos de los métodos. Esta información está disponible para aplicaciones de escritorio, tienda Windows y Windows Phone. Para más información, vea Examinar los valores devueltos de llamadas a métodos.

  • Editar y continuar para aplicaciones de 64 bits. Visual Studio 2013 admite la característica Editar y continuar para aplicaciones administradas de 64 bits para escritorio, Tienda Windows y Windows Phone. Las limitaciones existentes permanecen vigentes para las aplicaciones de 32 y 64 bits (consulte la última sección del artículo Supported Code Changes (C#)).

  • Depuración asincrónica. Para facilitar la depuración de aplicaciones asincrónicas en Visual Studio 2013, la pila de llamadas oculta el código de infraestructura proporcionado por los compiladores para permitir la programación asincrónica y, además, encadena los principales marcos lógicos para que pueda seguir la ejecución lógica del programa con mayor claridad. Una ventana Tareas reemplaza la ventana Tareas paralelas y muestra las tareas relacionadas con un punto de interrupción determinado y también muestra cualquier otra tarea que esté activa o programada actualmente en la aplicación. Puede obtener más información sobre esta característica en la sección "Async-aware debugging" (Depuración asincrónica) de la publicación sobre el anuncio de .NET Framework 4.5.1.

  • Mejor compatibilidad con excepciones para los componentes de Windows Runtime. En Windows 8.1, las excepciones que surgen de las aplicaciones de la Tienda Windows conservan información sobre el error que provocó la excepción, incluso a través de los límites del idioma. Puede obtener más información sobre esta característica en la sección "Windows Store app development" (Desarrollo de aplicaciones de la Tienda Windows) de la publicación del anuncio de .NET Framework 4.5.1.

A partir de Visual Studio 2013, puedes usar la herramienta de optimización guiada por perfiles administrados (Mpgo.exe) para optimizar las aplicaciones de la Tienda Windows 8.x, así como las aplicaciones de escritorio.

Para descubrir las nuevas características de ASP.NET 4.5.1, vea ASP.NET and Web Tools for Visual Studio 2013 Release Notes (Notas de la versión de ASP.NET y herramientas web para Visual Studio 2013).

Novedades de .NET Framework 4.5

Clases base

  • Capacidad para reducir los reinicios del sistema mediante la detección y el cierre de aplicaciones de .NET Framework 4 durante la implementación. Consulte el documento sobre la reducción de reinicios del sistema durante las instalaciones de .NET Framework 4.5.

  • Compatibilidad con matrices que tienen más de 2 gigabytes (GB) en plataformas de 64 bits. Esta característica se puede habilitar en el archivo de configuración de la aplicación. Consulte el <elemento gcAllowVeryLargeObjects>, que también enumera otras restricciones sobre el tamaño de objeto y el tamaño de matriz.

  • Mejor rendimiento mediante la recolección de basura en segundo plano para servidores. Cuando se usa la recolección de elementos no utilizados de los servidores en .NET Framework 4.5, se habilita automáticamente la recolección de elementos no utilizados en segundo plano. Vea la sección sobre la recolección de elementos no utilizados en segundo plano de los servidores del tema Fundamentos de la recolección de elementos no utilizados.

  • Compilación Just-in-time (JIT) en segundo plano, que se encuentra disponible opcionalmente en los procesadores de varios núcleos para mejorar el rendimiento de la aplicación. Vea ProfileOptimization.

  • Capacidad de limitar cuánto tiempo intentará el motor de expresiones regulares resolver una expresión regular antes de que se agote el tiempo de espera. Consulte la propiedad Regex.MatchTimeout.

  • Capacidad de definir la referencia cultural predeterminada para un dominio de aplicación. Vea la descripción de la clase CultureInfo.

  • Compatibilidad de la consola con codificación Unicode (UTF-16). Vea la descripción de la clase Console.

  • Compatibilidad con el control de versiones de ordenación cultural de cadenas y datos de comparación. Vea la descripción de la clase SortVersion.

  • Mejor rendimiento al recuperar recursos. ConsulteEmpaquetado e implementación de recursos.

  • Mejoras de compresión zip para reducir el tamaño de un archivo comprimido. Consulte el espacio de nombres System.IO.Compression.

  • Capacidad de personalizar un contexto de reflexión para invalidar el comportamiento de reflexión predeterminado a través de la clase CustomReflectionContext.

  • Compatibilidad con la versión 2008 de los nombres de dominio internacionalizados en aplicaciones (IDNA) estándar cuando se usa la clase System.Globalization.IdnMapping en Windows 8.

  • Delegación de la comparación de cadenas al sistema operativo, que implementa Unicode 6.0, cuando se usa el .NET Framework en Windows 8. Al ejecutarse en otras plataformas, .NET Framework incluye sus propios datos de comparación de cadenas, que implementa Unicode 5.x. Vea la clase String y la sección Comentarios de la clase SortVersion.

  • Capacidad de calcular los códigos hash de las cadenas por dominio de aplicación. Consulte el elemento <UseRandomizedStringHashAlgorithm> .

  • Compatibilidad con la reflexión de tipos dividida entre las clases Type y TypeInfo. Vea Reflexión en .NET Framework para aplicaciones de la Tienda Windows.

Managed Extensibility Framework (MEF) - Marco de Extensibilidad Gestionado (MEF)

En .NET Framework 4.5, Managed Extensibility Framework (MEF) proporciona las siguientes características nuevas:

  • Compatibilidad con tipos genéricos.

  • Modelo de programación basado en convención que permite crear elementos basados en convenciones de nomenclatura en lugar de atributos.

  • Varios ámbitos.

  • Subconjunto de MEF que puedes usar al crear aplicaciones de la Tienda Windows 8.x. Este subconjunto está disponible como un paquete descargable en la galería de NuGet. Para instalar el paquete, abra su proyecto en Visual Studio, elija Administrar paquetes NuGet desde el menú Project, y busque en línea el paquete de Microsoft.Composition.

Para obtener más información, vea Managed Extensibility Framework (MEF).

Operaciones de archivos asincrónicas

En .NET Framework 4.5, se agregaron nuevas características asincrónicas a los lenguajes C# y Visual Basic. Estas características agregan un modelo basado en tareas para realizar operaciones asincrónicas. Para usar este nuevo modelo, use los métodos asincrónicos en las clases de E/S. Vea E/S de archivos asincrónica.

Herramientas

En .NET Framework 4.5, el Generador de archivos de recursos (Resgen.exe) permite crear un archivo .resw para su uso en aplicaciones de la Tienda Windows 8.x desde un archivo .resources incrustado en un ensamblado de .NET Framework. Para obtener más información, consulte Resgen.exe (Generador de archivos de recursos).

La optimización guiada por perfiles administrados (Mpgo.exe) le permite mejorar el tiempo de inicio de la aplicación, el uso de memoria (tamaño del conjunto de trabajo) y el rendimiento mediante la optimización de ensamblados de imágenes nativas. La herramienta de línea de comandos genera datos de perfil para ensamblados de aplicación de imagen nativa. Consulte Mpgo.exe (Herramienta de optimización guiada por perfiles administrados). A partir de Visual Studio 2013, puedes usar Mpgo.exe para optimizar las aplicaciones de la Tienda Windows 8.x, así como las aplicaciones de escritorio.

Computación en paralelo

.NET Framework 4.5 proporciona varias características y mejoras nuevas para la informática en paralelo. Estos incluyen un rendimiento mejorado, un mayor control, una compatibilidad mejorada con la programación asincrónica, una nueva biblioteca de flujos de datos y una compatibilidad mejorada con la depuración en paralelo y el análisis de rendimiento. Consulte la entrada Novedades del paralelismo en .NET Framework 4.5 en el blog Programación paralela con .NET.

Web

ASP.NET 4.5 y 4.5.1 añaden enlace de modelos para Web Forms, soporte para WebSocket, manejadores asincrónicos, mejoras de rendimiento y muchas otras características. Para obtener más información, consulte los siguientes recursos:

Redes

.NET Framework 4.5 proporciona una nueva interfaz de programación para aplicaciones HTTP. Para obtener más información, consulte los nuevos espacios de nombres System.Net.Http y System.Net.Http.Headers.

También se incluye compatibilidad con una nueva interfaz de programación para aceptar e interactuar con una conexión WebSocket mediante el uso de las clases existentes HttpListener y relacionadas. Para obtener más información, consulte el nuevo espacio de nombres System.Net.WebSockets y la clase HttpListener.

Además, .NET Framework 4.5 incluye las siguientes mejoras de red:

  • Compatibilidad de URI conforme a RFC. Para obtener más información, consulte Uri y clases relacionadas.

  • Compatibilidad con el análisis de nombres de dominio internacionalizados (IDN). Para obtener más información, consulte Uri y clases relacionadas.

  • Compatibilidad con la internacionalización de direcciones de correo electrónico (EAI). Para obtener más información, consulte el espacio de nombres System.Net.Mail.

  • Compatibilidad mejorada con IPv6. Para obtener más información, consulte el espacio de nombres System.Net.NetworkInformation.

  • Compatibilidad con el socket de modo dual. Para obtener más información, consulte las clases Socket y TcpListener.

Windows Presentation Foundation (WPF)

En .NET Framework 4.5, Windows Presentation Foundation (WPF) contiene cambios y mejoras en las siguientes áreas:

  • El nuevo control Ribbon, que le permite implementar una interfaz de usuario tipo cinta que alberga una barra de herramientas de acceso rápido, un menú de aplicaciones y pestañas.

  • La nueva interfaz INotifyDataErrorInfo, que admite la validación de datos sincrónica y asincrónica.

  • Nuevas características para las clases VirtualizingPanel y Dispatcher.

  • Se ha mejorado el rendimiento al mostrar grandes conjuntos de datos agrupados y acceder a colecciones en subprocesos que no son de interfaz de usuario.

  • Enlace de datos a propiedades estáticas, enlace de datos a tipos personalizados que implementan la interfaz ICustomTypeProvider y recuperación de información de enlace de datos desde una expresión de enlace.

  • Cambiar la posición de los datos a medida que cambian los valores (forma dinámica).

  • Capacidad de comprobar si el contexto de datos de un contenedor de elementos está desconectado.

  • Capacidad de establecer la cantidad de tiempo que debe transcurrir entre los cambios de propiedad y las actualizaciones del origen de datos.

  • Soporte mejorado para la implementación de patrones de eventos débiles. Además, los eventos ahora pueden aceptar extensiones de marcado.

Windows Communication Foundation (WCF)

En .NET Framework 4.5, se han agregado las siguientes características para facilitar la escritura y el mantenimiento de aplicaciones de Windows Communication Foundation (WCF):

  • Simplificación de los archivos de configuración generados.

  • Compatibilidad con el desarrollo del contrato en primer lugar.

  • Capacidad de configurar ASP.NET modo de compatibilidad más fácilmente.

  • Cambios en los valores de propiedad de transporte predeterminados para reducir las probabilidades de tener que establecerlos.

  • Actualizaciones de la clase XmlDictionaryReaderQuotas para reducir la probabilidad de que tenga que configurar manualmente cuotas para lectores de diccionarios XML.

  • Validación de los archivos de configuración de WCF de Visual Studio como parte del proceso de compilación, por lo que puede detectar errores de configuración antes de ejecutar la aplicación.

  • Nueva compatibilidad con streaming asincrónico.

  • Nueva asignación del protocolo HTTPS para facilitar la exposición de un extremo a través de HTTPS con Internet Information Services (IIS).

  • Capacidad de generar metadatos en un único documento WSDL anexando ?singleWSDL a la dirección URL del servicio.

  • Soporte de Websockets para habilitar la verdadera comunicación bidireccional a través de los puertos 80 y 443 con características de rendimiento similares a las del transporte TCP.

  • Compatibilidad con la configuración de servicios en el código.

  • Información sobre herramientas del Editor XML.

  • compatibilidad con el almacenamiento en caché ChannelFactory.

  • Compatibilidad con la compresión del codificador binario.

  • Compatibilidad con un transporte UDP que permite a los desarrolladores escribir servicios que utilizan mensajería de tipo "desencadenar y omitir”. Un cliente envía un mensaje a un servicio y no espera ninguna respuesta del servicio.

  • Capacidad de admitir varios modos de autenticación en un único punto de conexión WCF cuando se usa el transporte HTTP y la seguridad de transporte.

  • Compatibilidad con servicios WCF que usan nombres de dominio internacionalizados (IDN).

Para obtener más información, vea Novedades de Windows Communication Foundation.

Windows Workflow Foundation (WF)

En .NET Framework 4.5, se agregaron varias características nuevas a Windows Workflow Foundation (WF), entre las que se incluyen:

  • Flujos de trabajo de máquina de estado, que fueron introducidos por primera vez como parte de .NET Framework 4.0.1 (.NET Framework 4 Platform Update 1). Esta actualización incluía varias clases y actividades nuevas que permitían a los desarrolladores crear flujos de trabajo de máquina de estado. Estas clases y actividades se actualizaron para .NET Framework 4.5 para incluir:

    • Capacidad de establecer puntos de interrupción en estados

    • La capacidad de copiar y pegar transiciones en el diseñador de flujo de trabajo.

    • Compatibilidad del diseñador para la creación de transiciones de desencadenador compartidas

    • Actividades para crear flujos de trabajo de máquina de estados, incluidas: StateMachine, State y Transition

  • Características mejoradas del Diseñador de flujos de trabajo, como las siguientes:

    • Funciones de búsqueda mejoradas en procesos de trabajo en Visual Studio, incluidas Búsqueda Rápida y Buscar en Archivos.

    • Capacidad de crear automáticamente una actividad de secuencia cuando se agrega una segunda actividad secundaria a una actividad contenedora e incluir ambas actividades en la actividad de secuencia.

    • Compatibilidad con el movimiento panorámico, que permite cambiar la parte visible de un flujo de trabajo sin usar las barras de desplazamiento.

    • Una nueva vista Esquema del documento, en la que se muestran los componentes de un flujo de trabajo en una vista de esquema con forma de árbol y que le permite seleccionar un componente en la vista Esquema del documento.

    • Capacidad de agregar anotaciones a las actividades.

    • Capacidad de definir y consumir delegados de actividad mediante el Diseñador de flujo de trabajo.

    • Conexión e inserción automáticas para actividades y transiciones en los flujos de trabajo de máquina de estados y diagrama de flujo.

  • Almacenamiento de la información de estado de vista de un flujo de trabajo en un único elemento del archivo XAML, por lo que puedes localizar y editar fácilmente la información de estado de vista.

  • Una actividad de contenedor NoPersistScope para evitar que se conserven las actividades secundarias.

  • Compatibilidad con expresiones de C#:

    • Los proyectos de flujo de trabajo que usan Visual Basic usarán expresiones de Visual Basic y los proyectos de flujo de trabajo de C# usarán expresiones de C#.

    • Los proyectos de flujo de trabajo de C# creados en Visual Studio 2010 y que tienen expresiones de Visual Basic son compatibles con proyectos de flujo de trabajo de C# que usan expresiones de C#.

  • Mejoras de control de versiones:

    • La nueva clase WorkflowIdentity, que proporciona una asignación entre una instancia de flujo de trabajo persistente y su definición de flujo de trabajo.

    • Ejecución en paralelo de varias versiones de flujo de trabajo en el mismo host, incluida WorkflowServiceHost.

    • En Actualización dinámica, la capacidad de modificar la definición de una instancia de flujo de trabajo persistente.

  • Desarrollo de servicios de flujo de trabajo basado en el contrato, que proporciona soporte para generar automáticamente actividades que se ajusten a un contrato de servicio existente.

Para obtener más información, vea Novedades de Windows Workflow Foundation.

.NET para aplicaciones de Tienda de Windows 8.x

Las aplicaciones de la Tienda Windows 8.x están diseñadas para factores de forma específicos y aprovechan la eficacia del sistema operativo Windows. Hay disponible un subconjunto de .NET Framework 4.5 o 4.5.1 para compilar aplicaciones de la Tienda Windows 8.x para Windows mediante C# o Visual Basic. Este subconjunto se denomina .NET para aplicaciones de la Tienda Windows 8.x y se explica en una introducción.

Bibliotecas de clases portables

El proyecto Biblioteca de clases portable de Visual Studio 2012 (y versiones posteriores) le permite escribir y compilar ensamblados administrados que funcionan en varias plataformas de .NET Framework. Con un proyecto de biblioteca de clases portátil, se pueden elegir las plataformas (como Windows Phone y .NET para aplicaciones de la Tienda Windows 8.x) a las que quieres dirigirte. Los tipos y miembros disponibles del proyecto se restringen automáticamente a los tipos y miembros comunes en estas plataformas. Para obtener más información, vea Biblioteca de clases portátil.

Consulte también