Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
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á incluida con Windows, sin planes de quitarlo. No es necesario migrar las aplicaciones de .NET Framework, pero para el nuevo desarrollo, use .NET en lugar de .NET Framework.
En este artículo se resumen las nuevas características y mejoras clave de las siguientes versiones de .NET Framework:
- .NET Framework 4.8.1
- .NET Framework 4.8
- .NET Framework 4.7.2
- .NET Framework 4.7.1
- .NET Framework 4.7
- .NET Framework 4.6.2
- .NET Framework 4.6.1
- .NET 2015 y .NET Framework 4.6
- .NET Framework 4.5.2
- .NET Framework 4.5.1
- .NET Framework 4.5
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 Getting Started. 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 vectores habilitados para SIMD. Para obtener más información, vea Bibliotecas de clases y API y .NET Framework y versiones fuera de banda. Consulte una lista complete de paquetes NuGet para .NET Framework.
Presentación de .NET Framework 4.8.1
.NET Framework 4.8.1 se basa en versiones anteriores de .NET Framework 4.x agregando muchas correcciones nuevas y varias características nuevas, mientras que permanecen en 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:
- Instalador web de .NET Framework 4.8.1
- Instalador sin conexión de .NET Framework 4.8.1
.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 tener como destino .NET Framework 4.8.1 en Visual Studio 2022 17.3 o posterior mediante la instalación de .NET Framework 4.8.1 Developer Pack.
Novedades de .NET Framework 4.8.1
.NET Framework 4.8.1 presenta nuevas características en las siguientes áreas:
- compatibilidad nativa de con arm64
- Información sobre herramientas accesible conforme con WCAG2.1
- Windows Forms– Mejoras de accesibilidad
Accesibilidad mejorada, que permite a una aplicación proporcionar una experiencia adecuada para los usuarios de la 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 .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, tanto Windows Forms como 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 la gestión de los tooltips para mejorar su accesibilidad. 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 Windows 11 o en sistemas operativos posteriores. Windows Forms es un contenedor administrado delgado en torno a la API de Windows, y el nuevo comportamiento de las herramientas emergentes solo se ha vuelto disponible en Windows 11. WPF no tiene dependencias de versiones del sistema operativo para sus informaciones sobre herramientas accesibles.
WPF había implementado la mayoría de los requisitos de información sobre herramientas compatibles con WCAG2.1 en .NET Framework 4.8. En esta versión, WPF mejoró la experiencia al asegurarse de que un tooltip en la ventana actual se puede descartar fácilmente usando la tecla Esc, la tecla Ctrl (por sí sola), o con 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 desarrollada para el .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:
Text pattern support– Windows Forms 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.
Presentación de .NET Framework 4.8
.NET Framework 4.8 se basa en versiones anteriores de .NET Framework 4.x agregando muchas correcciones nuevas y varias características nuevas, mientras que permanecen un producto muy estable.
Descarga e instalación de .NET Framework 4.8
Puede descargar .NET Framework 4.8 desde las siguientes ubicaciones:
instalador web de .NET Framework 4.8
Instalador sin conexión de NET Framework 4.8
.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 tener como destino .NET Framework 4.8 en Visual Studio 2012 o posterior mediante la instalación de .NET Framework 4.8 Developer Pack.
Novedades de .NET Framework 4.8
.NET Framework 4.8 presenta nuevas características en las siguientes áreas:
- Clases base
- Windows Communication Foundation (WCF)
- Windows Presentation Foundation (WPF)
- Common Language Runtime
Accesibilidad mejorada, que permite a una aplicación proporcionar una experiencia adecuada para los usuarios de la 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 una 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 que tienen como destino .NET Framework 4.8, las siguientes clases de criptografía administradas ya no inician una CryptographicException en este caso:
- MD5Cng
- MD5CryptoServiceProvider
- RC2CryptoServiceProvider
- RijndaelManaged
- RIPEMD160Managed
- SHA256Managed
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 en . 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 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 desflate. La versión .NET Framework 4.8 de clrcompression.dll se actualiza para usar ZLib versión 1.2.11, 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 . Cuando un comportamiento de servicio se agrega a la colección , 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 . 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 , , , ) 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:
EnCasoDeFalloDelServicio:
Se devuelve un código de estado de respuesta HTTP 450 cuando ServiceHost.State es mayor que .
Parámetros y ejemplos de consulta:
OnDispatcherFailure:
se devuelve un código de estado de respuesta HTTP 455 cuando el estado de cualquier distribuidor de canal es mayor que .
OnListenerFailure:
se devuelve un código de estado de respuesta HTTP 465 cuando el estado de cualquiera de las escuchas de canales es mayor que .
OnThrottlePercentExceeded:
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 o en XML especificando una cadena de consulta como . Una cadena de consulta como devuelve una página HTML vacía.
Windows Presentation Foundation (WPF)
Altas mejoras de PPP
En .NET Framework 4.8, WPF agrega compatibilidad con la conciencia de DPI de Per-Monitor V2 y el escalado de DPI en modo mixto. Consulte High DPI Desktop Application Development on Windows para obtener información adicional sobre el desarrollo de aplicaciones de escritorio con alta resolución PPP en Windows.
.NET Framework 4.8 mejora la compatibilidad con HWNDs hospedados y la interoperación con Windows Forms en aplicaciones WPF de DPI alto en plataformas que admiten el escalado de PPP de modo mixto (a partir de la actualización de abril de 2018 de Windows 10). Cuando se crean HWND hospedados o controles de Windows Forms como ventanas de DPI Mixed-Mode al llamar a SetThreadDpiHostingBehavior y SetThreadDpiAwarenessContext, pueden hospedarse en una aplicación de Per-Monitor V2 WPF y tienen el tamaño y la escala adecuados. 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 Per-Monitor v2 también permite alojar controles WPF en una ventana nativa dentro de una aplicación de alta PPP.
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 runtime 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 , no se examinan y pueden contener malware no detectado. A partir del .NET Framework 4.8 ejecutándose en Windows 10, el tiempo de ejecución inicia un análisis mediante soluciones antimalware que implementan la interfaz de análisis 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 y permiten proporcionar parámetros clave al crear instancias de una nueva clave de o . 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 y permiten generar nuevas claves o 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 de hashing
La clase tiene tres constructores nuevos con un parámetro 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 en un constructor de o en una de las sobrecargas del método , 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 cargadas de esta manera casi siempre se cargan a través de Windows CNG. 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 no funciona.
Dado que la propiedad 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 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 .
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 ajustado. Para dejar abierta la secuencia envuelta después de desechar la instancia de , llame al nuevo constructor 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 />
La compatibilidad con la descompresión mediante Windows API está habilitada de forma predeterminada para las aplicaciones destinadas a .NET Framework 4.7.2. Las aplicaciones destinadas a 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 varias API nuevas a los tipos de SortedSet<T> y HashSet<T>. Estos incluyen:
Los métodos , que amplían el patrón de try que se usa en otros tipos de colección a estos dos tipos. Los métodos son:
- public bool HashSetT. TryGetValue(T equalValue, out T actualValue)
- public bool SortedSetT. TryGetValue(T equalValue, out T actualValue)
Los métodos de extensión , que convierten una colección en un :
- public static HashSetTSource ToHashSetTSource(this IEnumerableTSource source)
- public static HashSetTSource ToHashSetTSource(this IEnumerableTSource source, IEqualityComparerTSource comparer)
Nuevos constructores de que permiten establecer la capacidad de la colección, lo que da como resultado una mejora del rendimiento cuando se conoce el tamaño de con antelación:
- public HashSet(int capacity)
- public HashSet(int capacidad, IEqualityComparerT comparador)
La clase incluye nuevas sobrecargas de los métodos y 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 de ASP.NET destinadas a .NET Framework 4.7.2, puede hacer lo siguiente:
Usar la inserción basada en setters, basada en interfaces y basada en constructores en handlers y módulos, instancias de páginas y controles de usuario de proyectos de aplicaciones web de ASP.NET.
Use la inyección basada en establecedores e inyección basada en interfaces en handlers y módulos, instancias de página y controles de usuario de proyectos de sitios web de ASP.NET.
Conecte diferentes marcos de inserción de dependencias.
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 , así como a las cookies y .
Puede establecer SameSite para un objeto 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 y 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 . .NET Framework 4.7.2 ahora proporciona una implementación para estas propiedades. Las propiedades son:
SQLClient
Support para 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, .NET Framework 4.7.2 amplía las cadenas de conexión de SQLClient al agregar un nuevo valor, "Active Directory Interactivo", para la palabra clave existente "Authentication" a fin de admitir MFA y la Autenticación de Azure AD. El nuevo método interactivo admite a usuarios nativos y federados de Azure AD, así como a 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 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 el cadena de conexión.
Para obtener más información y un ejemplo, consulte "SQL -- Compatibilidad con la Autenticación Universal y Multifactor de Azure AD" en el .NET Blog.
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, si lo desea, enviar las claves de cifrado a un enclave seguro, que es una entidad de computación segura que se puede considerar parte de SQL Server, pero con la que el código de SQL Server no puede interferir. Para admitir Always Encrypted basado en enclave, .NET Framework 4.7.2 agrega los siguientes tipos y miembros al espacio de nombres System.Data.SqlClient:
, que especifica el URI para Always Encrypted basado en enclaves.
, que es una clase abstracta de la que se derivan todos los proveedores de enclave.
, que encapsula el estado de una sesión de enclave determinada.
SqlEnclaveAttestationParameters, que proporciona los parámetros de atestación usados por SQL Server para obtener información necesaria para ejecutar un protocolo de atestación determinado.
A continuación, el archivo de configuración de la aplicación especifica una implementación concreta de la clase abstracta 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:
El usuario crea una conexión Always Encrypted a un SQL Server que admite 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.
Una vez atestiguado el enclave, el controlador establece un canal seguro con el enclave seguro hospedado en SQL Server.
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 ResourceDictionaries que se han creado desde un URI de origen dado. (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, . 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 esté habilitado y se establezca la variable de entorno .
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 ResourceDictionary determinado. (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 DynamicResource que podrían verse afectadas por el cambio.
Es posible que un asistente de diagnóstico, como la funcionalidad "Editar y continuar" de Visual Studio, quiera ampliarlo para manejar las referencias de StaticResource. El primer paso de este proceso es buscar los propietarios del diccionario; es decir, para buscar todos los objetos cuya propiedad hace referencia al diccionario (directa o indirectamente a través de la propiedad ). 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 esté habilitado y se establezca la variable de entorno .
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 es utilizada por asistentes de diagnóstico, no por aplicaciones de producción). Un asistente de diagnóstico como la función 'Editar y continuar' de Visual Studio puede querer actualizar todos los usos de un recurso cuando cambia su valor en un ResourceDictionary. WPF hace esto automáticamente para las referencias de DynamicResource, pero no lo hace intencionadamente para las referencias 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 :
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 describen la resolución e indican el objeto y la propiedad que hospedan la referencia StaticResource y el objeto 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 ), a menos que esté habilitado y se establezca la variable de entorno .
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 alternativa anterior de establecer la compatibilidad con DPI en el archivo de configuración de la aplicación en lugar del manifiesto de la aplicación ya no es necesaria para que la implementación con ClickOnce tenga éxito.
Novedades de .NET Framework 4.7.1
.NET Framework 4.7.1 incluye nuevas características en las siguientes áreas:
- Clases base
- Common Language Runtime: CLR
- Redes
- ASP.NET
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
Support para .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 admite totalmente .NET Standard 2.0 y agrega about 200 API que se definen en .NET Standard 2.0 y 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 soporte técnico estándar .NET adicionales en el sistema de destino). Para obtener más información, vea "BCL - .NET compatibilidad con Standard 2.0" en la entrada de blog .NET Framework 4.7.1 Runtime and Compiler Features.
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 abstracta y reemplace sus métodos y . También defines tus builders en el archivo .config. Para obtener más información, vea 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 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 y , a tipos value tuple. Para obtener más información, consulte "Compilador: ValueTuple es Serializable" en el artículo del blog .NET Framework 4.7.1 Runtime and Compiler Features.
Compatibilidad con referencias de solo lectura
.NET Framework 4.7.1 agrega el 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 ref, vea Valores devueltos ref y Localizaciones ref y Valores devueltos ref (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 (GC) en .NET Framework 4.7.1 mejoran el rendimiento general, especialmente para las asignaciones de montón de objetos grandes (LOH). En .NET Framework 4.7.1, se emplean bloqueos independientes para las asignaciones de montón de objetos pequeños (SOH) y de montón de objetos grandes (LOH), lo que permite que las asignaciones del LOH se produzcan cuando la GC en segundo plano está ejecutando el barrido del SOH. 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, vea 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.Sha384 y HashAlgorithm.Sha512. Si este valor se usa realmente depende de MSMQ, ya que la propia instancia de no realiza ningún hash, sino que simplemente pasa valores a MSMQ. Para obtener más información, vea 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 solicitudes en una canalización predefinida que incluye 23 eventos. ASP.NET ejecuta cada controlador de eventos como un 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 a la conmutación entre hilos nativos y administrados. En su lugar, ASP.NET fluye 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 la entrada de blog "Característica de paso de ejecución de ASP.NET" en .NET Framework 4.7.1 ASP.NET y características de configuración.
ASP.NET análisis de HttpCookie
.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 obtener más información, vea "análisis de HttpCookie de ASP.NET" en la entrada de blog .NET Framework 4.7.1 ASP.NET y Características de Configuración.
Opciones de hash SHA-2 para las credenciales de autenticación de formularios de ASP.NET
En .NET Framework 4.7 y versiones anteriores, ASP.NET permitía 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 te conectas a Azure SQL, 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:
- Clases base
- Redes
- ASP.NET
- Windows Communication Foundation (WCF)
- Windows Forms
- Windows Presentation Foundation (WPF)
Para obtener una lista de las nuevas API agregadas a .NET Framework 4.7, consulte .NET Framework 4.7 API Changes on GitHub. Para obtener una lista de las mejoras de características y las 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 Announcing .NET Framework 4.7 en el blog de .NET.
Clases base
.NET Framework 4.7 mejora la serialización mediante DataContractJsonSerializer:
funcionalidad mejorada con criptografía de curva elíptica (ECC)
En .NET Framework 4.7, se agregaron ImportParameters(ECParameters) métodos a las ECDsa y ECDiffieHellman clases para permitir que un objeto represente una clave ya existente. También se agregó un método 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 una example de 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 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
ICacheStoreProvider.Supervisión de memoria. El monitor de memoria predeterminado en 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 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 o la cantidad de caché que se recorta son ineficaz. Los desarrolladores ahora pueden reemplazar o complementar el comportamiento predeterminado suscribiendo implementaciones 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.
- Se ha mejorado la confiabilidad al anular una conexión con y DuplexChannelBinder.
- Se ha mejorado la confiabilidad de las operaciones de serialización al llamar al método .
- 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 que tienen como destino .NET Framework 4.7, .NET Framework cuenta con una compatibilidad de PPP elevada y dinámica con PPP para 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 de activación que se configura definiendo una sección <System.Windows.Forms.ConfigurationSection> en el archivo de configuración de la aplicación. Para obtener más información sobre cómo agregar compatibilidad de DPI alto y compatibilidad con DPI dinámico a la aplicación de Windows Forms, consulte Compatibilidad de DPI alto en Windows Forms.
Windows Presentation Foundation (WPF)
En .NET Framework 4.7, WPF incluye las siguientes mejoras:
Soporte para una pila de entrada táctil/lápiz basada en mensajes de Windows WM_POINTER
Ahora tiene la opción de usar una pila táctil o de lápiz basada en mensajes WM_POINTER en lugar de la Plataforma de Servicios de Tinta de Windows (WISP). Es una característica opcional en .NET Framework. Para obtener más información, consulte la sección compatibilidad de aplicaciones.
Nueva implementación para las API de impresión de WPF
Las API de impresión de WPF en la clase System.Printing.PrintQueue llaman a la API Print Document Package de Windows en lugar de la obsoleta API XPS Print. 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:
Categorías de caracteres
Criptografía
SqlClient
ClickOnce
Conversión de aplicaciones Windows Forms y WPF a aplicaciones UWP
Mejoras en la depuración
Para obtener una lista de las nuevas API agregadas a .NET Framework 4.6.2, consulte .NET Framework 4.6.2 API Changes on 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 Announcing .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 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:
El se proporciona en el atributo de validación.
El archivo de recursos se almacena en la carpeta App_LocalResources.
El nombre del archivo de recursos localizados tiene la forma nombre, donde nombre es un nombre de referencia cultural en el formato códigoDeIdiomacódigoDePaís/Región o códigoDeIdioma.
El nombre de clave del recurso es la cadena asignada al atributo 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 . 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 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
ASP.NET ahora permite usar métodos que devuelven tareas con proveedores de almacenamiento de estado de sesión, lo que permite a las aplicaciones ASP.NET obtener los beneficios de escalabilidad del uso de métodos asincrónicos. 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 incluye dos métodos nuevos, y , 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:
La clase , que hereda de y permite a los desarrolladores implementar un proveedor asincrónico de caché de salida.
La clase , que proporciona métodos auxiliares para configurar la caché de salida.
18 nuevos métodos en la clase . Estos incluyen , , , , , , , , , , , , , y .
2 nuevos métodos de la clase : y .
2 nuevos métodos de la clase : y .
2 nuevos métodos de la clase : y .
En la clase , el método .
En la clase , el método .
Categorías de caracteres
Los caracteres de .NET Framework 4.6.2 se clasifican en función de la Unicode Standard, 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 y a los tipos y métodos que se basan en él. Estos incluyen la StringInfo clase, el método sobrecargado Char.GetUnicodeCategory, 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 de 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 proporciona compatibilidad con FIPS 186-3.
En consonancia con los cambios recientes en la clase RSA en .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 llamadores usen esta funcionalidad sin conversión. Puede llamar al método de extensión 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 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 agregó soporte para el acuerdo de clave Elliptic Curve Diffie-Hellman con tres rutinas diferentes de Key Derivation Function (KDF). Las entradas a las rutinas y las propias rutinas se configuraron a través de propiedades en el objeto . 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 (CNG) de Windows 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 ).
Existe compatibilidad con el cifrado simétrico de clave persistente para los algoritmos AES () y 3DES (). 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 PKCS#1 RSA-SHA256, RSA-SHA384 y RSA-SHA512, y para los algoritmos de resumen de referencia SHA256, SHA384 y SHA512.
Todas las constantes de URI se exponen en :
| 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 personalizado en 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 ya no es necesario.
SqlClient
.NET Framework Proveedor de datos para SQL Server (System.Data.SqlClient) incluye las siguientes características nuevas en .NET Framework 4.6.2:
Pools de conexiones y tiempos de espera con Azure SQL Database
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, consulte Agrupación de conexiones de SQL Server (ADO.NET).
Este comportamiento no es deseable al conectarse a Azure SQL Bases de datos, 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 pool de conexiones cuando fracasan las conexiones a las Bases de Datos de Azure SQL.
La adición de la nueva palabra clave permite seleccionar el período de bloqueo más adecuado para la aplicación. Los valores incluyen:
El período de bloqueo del grupo de conexiones para una aplicación que se conecta a un 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 Azure SQL Bases de datos:
.database.windows.net
.database.chinacloudapi.cn
.database.usgovcloudapi.net
.database.cloudapi.de
El período de bloqueo del grupo de conexiones siempre está habilitado.
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 establecida en (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 .
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 (CNG) de Windows. 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.
Para 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 siguiente línea a la <runtime> 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 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 usa el tipo en lugar del tipo de para deserializar los datos de fecha y hora. admite varias reglas de ajuste, lo que permite trabajar con datos históricos de zona horaria; no.
Para obtener más información sobre la estructura de 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 (valor predeterminado), es posible que los clientes que usen 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 , pero un servicio diferente en esa máquina que se ejecuta con privilegios de administrador está escuchando en . Con esta configuración de aplicación establecida en , el cliente intentaría conectarse al servicio incorrecto. Después de establecer la configuración de la aplicación en , el cliente siempre se conectará al mejor servicio coincidente.
Nota
Los clientes que usan 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.
La propiedad
La propiedad
La sección transport de la sección netTcpBinding
La sección sslStreamSecurity de la sección customBinding
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 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 y describen cómo ordenar la colección de grupos generados por el objeto . Esto es análogo a la forma en que las propiedades de con nombre idéntico describen cómo ordenar los elementos de datos.
Se pueden usar dos nuevas propiedades estáticas de la clase , y , 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 teclado táctil permite el seguimiento de foco en WPF aplicaciones invocando y descartando automáticamente el teclado táctil en Windows 10 cuando un control recibe la entrada táctil que puede tomar la entrada textual.
En versiones anteriores de .NET Framework, las aplicaciones de WPF no pueden habilitar el seguimiento de foco, sin deshabilitar la compatibilidad de gestos táctiles y de lápiz en WPF. Como resultado, las aplicaciones de WPF deben elegir entre la compatibilidad táctil completa de WPF, o confiar en la promoción del ratón de Windows.
PPP por monitor
Para admitir la reciente proliferación de entornos de ppp alto e híbrido-PPP para aplicaciones de WPF, WPF en .NET Framework 4.6.2 permite el reconocimiento por monitor. Consulte los ejemplos y la guía para desarrolladores en GitHub para obtener más información sobre cómo habilitar su aplicación WPF para que sea compatible con DPI por monitor.
En versiones anteriores de .NET Framework, las aplicaciones de WPF son conscientes del DPI 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.
En el caso de las aplicaciones que se ejecutan en .NET Framework 4.6.2, se puede desactivar los cambios de DPI por monitor en las aplicaciones WPF añadiendo una instrucción de configuración a la sección <runtime> 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 la siguiente área:
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 Visual Studio Designer 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, consulte el blog 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, WF Designer IntelliSense 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".
Propuestas de mejora del flujo de trabajo con el uso de la actualización dinámica en el Diseñador de flujos 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 . En versiones de .NET Framework antes de .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 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.
Conversión de aplicaciones 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 puede estar disponible para todos los dispositivos Windows 10.
Mejoras en la depuración
La API de depuración unmanaged se ha mejorado en .NET Framework 4.6.2 para realizar análisis adicionales cuando se produce un NullReferenceException para 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.
Las interfaces ICorDebugCode4, ICorDebugVariableHome e ICorDebugVariableHomeEnum, que exponen las ubicaciones nativas de las variables administradas. Esto permite a los depuradores realizar un análisis de flujo de código cuando ocurre un y trabajar hacia atrás para determinar la variable gestionada que corresponde a la ubicación nativa que fue .
El método ICorDebugType2::GetTypeID proporciona una asignación de ICorDebugType a COR_TYPEID, que permite al depurador obtener un COR_TYPEID sin una instancia de ICorDebugType. Las API existentes en COR_TYPEID se pueden usar para determinar el diseño de clase del tipo.
Novedades de .NET Framework 4.6.1
.NET Framework 4.6.1 incluye nuevas características en las siguientes áreas:
Criptografía
Generación de perfiles
NGen
Para obtener más información sobre .NET Framework 4.6.1, consulte los temas siguientes:
Compatibilidad de Aplicaciones en 4.6.1
.NET Framework API diff (en GitHub)
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.
El código de ejemplo siguiente 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 contraste marcado 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 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 el 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 , 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 en . 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 una serie de 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 ya no se bloquea el subproceso de representación durante la entrada rápida.
mejoras de revisión ortográfica
El corrector ortográfico de 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 Windows versiones anteriores a Windows 8.1.
Como en versiones anteriores de .NET Framework, se detecta el idioma de un control /> /
, si está presente.
Idioma de entrada actual.
Cultura actual.
Para obtener más información sobre la compatibilidad con idiomas en WPF, consulte la entrada de blog WPF en .NET Framework 4.6.1 features.
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 listas De palabras excluidas y 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 para WPF en las aplicaciones deben seguir usando archivos .lex.
Ejemplos
Hay varias muestras de WPF en el repositorio Microsoft/WPF-Samples GitHub. Ayúdanos a mejorar nuestros ejemplos enviando una solicitud de incorporación de cambios o abriendo un problema 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 on GitHub.
Windows Workflow Foundation: Transacciones
El método 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 . 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 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 del promotor de transacción puede obtenerse con la propiedad . Cuando se promueve la transacción, el promotor de transacciones proporciona una matriz de 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 .
Los usuarios de la nueva sobrecarga 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 sean compilados en memoria por 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 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 , , , , y . 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 trazado 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íneas de código fuente en la máquina B. Con las 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 entre máquinas, todo lo que se necesita es copiar la imagen PDB nativa generada por la Máquina A en la Máquina B y utilizar las APIs de Acceso a la Interfaz de Depuración para leer la asignación de origen a IL del PDB de IL y la asignación de IL a nativo del PDB de la imagen nativa. 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 lean 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 mediante herramientas de 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 mediante la compatibilidad de
async/awaitdel lenguaje.El enlace de modelos admite los métodos de devolución de tareas
En .NET Framework 4.5, ASP.NET agregó la característica de vinculación de modelos que habilitaba un enfoque extensible enfocado en el código para las operaciones de datos basadas en CRUD en páginas de formularios Web y controles de usuario. El sistema de enlace de modelos ahora admite métodos de enlace de modelos que devuelven . 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 .
<appSettings> <add key=" aspnet:EnableAsyncModelBinding" value="true|false" /> </appSettings>En las aplicaciones de destino .NET Framework 4.6, el valor predeterminado es
true. En las aplicaciones que se ejecutan en .NET Framework 4.6 que tienen como destino una versión anterior de .NET Framework, sefalsede forma predeterminada. Se puede habilitar estableciendo el valor de configuración en .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 de forma predeterminada para Windows 10 aplicaciones de la Plataforma universal de Windows (UWP) que usan la API de System.Net.Http.HttpClient.
Para proporcionar una manera de usar la característica
PUSH_PROMISE en aplicaciones de ASP.NET, se ha agregado un nuevo método con dos sobrecargas,y , a la clase /> 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 una característica del explorador. ASP.NET aplicaciones participarán en el protocolo, de modo que los tokens de autenticación se validen para que sean 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 era compatible con ASP.NET debido a 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 .
<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 , 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, que es especialmente beneficiosa para aplicaciones de 32 bits grandes (como Visual Studio) y también ahorra 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 IReadOnlyCollectionT
Las colecciones adicionales implementan , tales como y .
CultureInfo.CurrentCulture y CultureInfo.CurrentUICulture
Las propiedades y ahora son de lectura y escritura, en lugar de solo lectura. Si asigna un nuevo objeto a estas propiedades, la referencia cultural del subproceso actual definida por la propiedad y la referencia cultural del subproceso de interfaz de usuario actual definida por las propiedades de también cambian.
Mejoras en la recolección de basura (GC)
La clase ahora incluye los métodos y que permiten impedir la recolección de basura durante la ejecución de un camino crítico.
Una nueva sobrecarga del método 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 ahora incluye varios tipos habilitados para SIMD, como , , , , , y .
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 de
se está actualizando para admitir las API de criptografía de Windows CNG . Las versiones anteriores de .NET Framework se han basado completamente en una versión earlier 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 nuevas mejoras para admitir las API de criptografía de CNG de Windows:
Conjunto de métodos de extensión para certificados X509, y , 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 , 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 />
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 en .NET Framework 4.6 se puede volver a escribir como se indica a continuación 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 para admitir la conversión de valores de fecha y hora a o desde la hora de Unix:
Interruptores de compatibilidad
La clase 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 , 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 ) que define una biblioteca dependiente. El modificador siempre es implícitamente . Al configurar el interruptor en , se habilita. Establecer explícitamente el interruptor en 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 IfEs 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)
En el caso de las aplicaciones destinadas a .NET Framework 4.6, los objetos Task y Task<TResult> heredan la configuración regional y de interfaz de usuario del subproceso de 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 .
La clase permite representar datos ambientales locales a un flujo de control asincrónico determinado, como un método . 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 de forma explícita o porque el subproceso ha encontrado una transición de contexto.
Se han agregado tres métodos útiles, , y , al patrón asincrónico basado en tareas (TAP) para devolver tareas completadas en un estado determinado.
La clase ahora admite la comunicación asincrónica con su nueva . .
EventSource ahora admite la escritura en el registro de eventos
Ahora puede usar la clase 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 sobrecargado a la clase .
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 la TargetFrameworkAttribute está establecida en .NET Framework 4.6. Las aplicaciones destinadas a versiones anteriores del marco, pero que se ejecutan en .NET Framework 4.6 pueden participar en el nuevo comportamiento agregando la siguiente línea al <runtime> sección del archivo app.config:
<AppContextSwitchOverrides value="Switch.MS.Internal.DoNotApplyLayoutRoundingToMarginsAndBorderThickness=false" />Las ventanas de WPF que abarcan varios monitores con diferentes configuraciones de DPI (disposición de varios DPI) ahora se representan completamente sin regiones oscuras. Para desactivar este comportamiento, agregue la siguiente línea a la sección del archivo app.config para deshabilitar este nuevo comportamiento:
<add key="EnableMultiMonitorDisplayClipping" value="true"/>Se ha agregado compatibilidad para cargar automáticamente el cursor correcto según la configuración de PPP a System.Windows.Input.Cursor.
Mejor si es táctil
Los informes de los clientes en Connect sobre que la función táctil produce un comportamiento impredecible han sido solucionados en .NET Framework 4.6. El umbral de doble pulsación para las aplicaciones de Windows Store y las aplicaciones de WPF ahora es el mismo en Windows 8.1 y versiones posteriores.
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 en .
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 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 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 a .
<appSettings> <add key="wcf:httpTransportBinding:useUniqueConnectionPoolPerFactory" value="true" /> </appSettings>
Windows Workflow Foundation (WW)
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 del archivo app.config:
<add key="microsoft:WorkflowServices:FilterResumeTimeoutInSeconds" value="60"/>El valor predeterminado es 60 segundos. Si 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 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 . Para ello, agregue la siguiente clave a la sección del archivo app.config:
<add key="Transactions:IncludeDistributedTransactionIdInExceptionMessage" value="true"/>El valor predeterminado es .
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 de .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 provocando el 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:
El valor de enumeración .
Propiedad
De forma predeterminada, la propiedad es , a menos que el valor de la clave del Registro se establezca en 0x1. Para habilitar la reutilización del puerto local en conexiones HTTP, establezca la propiedad en . 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 permite la reutilización del puerto local.
Los desarrolladores que crean una aplicación solo de sockets pueden especificar la opción al llamar a un método (como ) 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, , a la clase para admitir mejor nombres de dominio internacionales y PunyCode.
Redimensionamiento en los controles de Windows Forms.
Esta característica se ha ampliado en .NET Framework 4.6 para incluir los DomainUpDown, NumericUpDown, DataGridViewComboBoxColumn, DataGridViewColumn y ToolStripSplitButton y el rectángulo especificado por la propiedad Bounds cuando se dibuja un UITypeEditor.
Esta es una función opcional. Para habilitarlo, establezca el elemento en 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 que no son compatibles con .NET Core registrando codificaciones de página de códigos con el método Encoding.RegisterProvider. Para obtener más información, consulte .
.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 Compilar 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, vea Getting Started with .NET Native.
Para admitir la depuración de aplicaciones .NET Native, se han agregado nuevas interfaces y enumeraciones a la API de depuración de código no administrado. Para obtener más información, consulte Depuración (referencia de API no administrada).
Paquetes de .NET Framework de origen abierto
.NET Core paquetes, como las colecciones inmutables, las API de SIMD y las API de red, como las que se encuentran en el espacio de nombres 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, .NET página principal en GitHub.
Novedades de .NET Framework 4.5.2
Nuevas API para aplicaciones de ASP.NET. Los nuevos métodos y 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 y ; son más eficientes y confiables.
El método 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 administrado ASP.NET.
Las nuevas propiedades y 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 (que producen excepciones si se han escrito los encabezados) se realizarán correctamente.
Redimensionar los controles 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.
Esta es una función opcional. Para habilitarlo, establezca el elemento en 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 (y, por tanto, la implementación de la interfaz ) puede usar el nuevo método para solicitar lo siguiente:
Promocionar la transacción a una transacción de MSDTC (Coordinador de transacciones distribuidas de Microsoft).
Reemplace con una , que es una inscripción duradera que admite confirmaciones de fase única.
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 al método 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:
- COR_PRF_ASSEMBLY_REFERENCE_INFO (estructura)
- COR_PRF_HIGH_MONITOR (Enumeración)
- GetAssemblyReferences (método)
- GetEventMask2 (método)
- SetEventMask2 (método)
- Método AddAssemblyReference
Las implementaciones de 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 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.
- SetWriteableMetadataUpdateMode (método)
- EnumerateLocalVariablesEx (método)
- GetLocalVariableEx (método)
- método GetCodeEx
- GetActiveReJitRequestILCode (método)
- Método GetInstrumentedILMap
Cambios en el seguimiento de eventos. .NET Framework 4.5.2 habilita el seguimiento de actividades fuera de proceso basado en Event Tracing for Windows (ETW) para un mayor ámbito 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 EnlistmentEl método se puede usar con una inscripción creada previamente por en respuesta al método . Pide a 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 ya no será referenciada por y las notificaciones futuras llegarán a la interfaz 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 para obtener más información. Además, la inscripción debe admitir . Solo se puede llamar a este método al procesar una llamada de . Si no es el caso, se produce una excepción .
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:
Puede 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 (Windows. Interfaz de usuario. Tipos XAML) en bibliotecas portátiles al dirigirse a 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 redirigir una biblioteca de clases de Windows Store o Windows Phone Store como una Biblioteca de Clases Portátil.
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 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 Compilar aplicaciones con .NET Native.
El .NET Framework Reference Source proporciona una nueva experiencia de exploración y una funcionalidad mejorada. Ahora puede navegar por el código fuente de .NET Framework en línea, descargar la referencia para verla sin conexión, y examinar paso a paso los orígenes (incluidas las revisiones y las actualizaciones) durante la depuración. Para obtener más información, consulte la entrada de blog Un nuevo look para .NET Reference Source.
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 y en la clase .
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 .
Mejoras de rendimiento adicionales, como la suspensión de aplicaciones de ASP.NET, mejoras en JIT de varios núcleos y un inicio de aplicación más rápido después de una actualización de .NET Framework. Para obtener más información, consulte el anuncio .NET Framework 4.5.1 y la entrada de blog sobre la suspensión de la aplicación ASP.NET.
Entre las mejoras de Windows Forms se incluyen las siguientes:
Cambiar el tamaño de los 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:
- PropertyGrid
- TreeView
- Algunos aspectos de (vea las nuevas características de la versión 4.5.2 para conocer los controles adicionales admitidos)
Para habilitar esta característica, agregue un elemento nuevo al archivo de configuración (app.config) y establezca el elemento en :
<appSettings> <add key="EnableWindowsFormsHighDpiAutoResizing" value="true" /> </appSettings>
Las mejoras al depurar las aplicaciones de .NET Framework en Visual Studio 2013 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 de valor devuelto y los valores de los métodos. Esta información está disponible para aplicaciones de escritorio, Windows Store 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, Windows Store y teléfono Windows. 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 admitir la programación asincrónica y también encadena marcos lógicos principales para que siga 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 leer sobre esta característica en la sección "Depuración asincrónica" del 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 las fronteras del idioma. Puedes leer sobre esta característica en la sección "desarrollo de aplicaciones de Windows Store" del .NET Framework 4.5.1 anuncio.
A partir de Visual Studio 2013, puedes usar Herramienta de optimización guiada por perfiles administrados (Mpgo.exe) para optimizar aplicaciones de la Tienda de Windows 8.x, así como aplicaciones de escritorio.
Para conocer las nuevas características de ASP.NET 4.5.1, consulte ASP.NET y Web Tools for Visual Studio 2013 Release Notes.
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 Reducir los 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. Vea el elemento , que también muestra 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 utilizas la recolección de basura del servidor en .NET Framework 4.5, la recolección de basura en segundo plano se habilita automáticamente. 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 .
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 .
Capacidad de definir la referencia cultural predeterminada para un dominio de aplicación. Vea la descripción de la clase .
Compatibilidad de la consola con codificación Unicode (UTF-16). Vea la descripción de la clase .
Compatibilidad con el control de versiones de ordenación cultural de cadenas y datos de comparación. Vea la descripción de la clase .
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 .
Capacidad de personalizar un contexto de reflexión para invalidar el comportamiento de reflexión predeterminado a través de la clase .
Compatibilidad con la versión 2008 del estándar de Nombres de Dominio Internacionalizados en Aplicaciones (IDNA) cuando se utiliza 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 .NET Framework en Windows 8. Al ejecutarse en otras plataformas, el .NET Framework incluye sus propios datos de comparación de cadenas, que implementa Unicode 5.x. Vea la clase y la sección Comentarios de la clase .
Capacidad de calcular los códigos hash de las cadenas por dominio de aplicación. Vea Elemento .
Compatibilidad con la reflexión de tipos dividida entre las clases y . Consulta Reflection en .NET Framework para Windows Store Apps.
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 el proyecto en Visual Studio, elija Administrar paquetes NuGet en el menú Project y busque en línea el paquete
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 usarlo 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 Windows 8.x Store, así como 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 agregan vinculación de modelos para Web Forms, compatibilidad con 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 y .
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 y relacionadas. Para obtener más información, consulte el nuevo espacio de nombres y la clase .
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 y clases relacionadas.
Compatibilidad con el análisis de nombres de dominio internacionalizados (IDN). Para obtener más información, consulte 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 .
Compatibilidad mejorada con IPv6. Para obtener más información, consulte el espacio de nombres .
Compatibilidad con el socket de modo dual. Para obtener más información, consulte las clases y .
Windows Presentation Foundation (WPF)
En .NET Framework 4.5, Windows Presentation Foundation (WPF) contiene cambios y mejoras en las siguientes áreas:
El nuevo control , 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 , que admite la validación de datos sincrónica y asincrónica.
Nuevas características para las clases y .
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 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 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 para reducir la probabilidad de que tenga que configurar manualmente cuotas para lectores de diccionarios XML.
Validación de archivos de configuración de WCF por 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 de protocolo HTTPS para facilitar la exposición de un punto de conexión a través de HTTPS con Internet Information Services (IIS).
Capacidad de generar metadatos en un único documento WSDL anexando 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é .
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 se introdujeron 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 que .NET Framework 4.5 incluya:
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: , y
Características mejoradas del Diseñador de flujos de trabajo, como las siguientes:
Funcionalidades de búsqueda de flujo de trabajo mejoradas en Visual Studio, incluidas Quick Find y Find 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 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 , 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 .
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, consulte What's New in Windows Workflow Foundation.
.NET para aplicaciones de la Tienda Windows 8.x
Windows 8.x Store Las aplicaciones 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 las aplicaciones de la Tienda Windows 8.x y se describe en un overview.
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, eliges las plataformas (como Windows Phone y .NET para las aplicaciones de la Tienda Windows 8.x) a las que apuntar. 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.