Cambios en .NET Framework 3.5 SP1
En este documento se describen los cambios de diseño que pueden tener en cuenta en la aplicación o el entorno al actualizar de .NET Framework versión 3.5 a .NET Framework versión 3.5 Service Pack 1 (SP1).
Los cambios se producen por varias razones, incluidas las correcciones de problemas del producto, el cumplimiento de estándares, los comentarios de los clientes y la seguridad. En este tema solo se describen los cambios importantes. Para obtener información sobre las nuevas características, vea Novedades de .NET Framework . Para proporcionar comentarios, visite el Centro de comentarios del producto de MSDN.
En las secciones siguientes se describen los cambios realizados en .NET Framework versión 3.5 SP1.
Common Language Runtime
Mejoras en el rendimiento Las aplicaciones ahora usan prevención de ejecución de datos para evitar intentos de insertar y ejecutar código desde ubicaciones de memoria no ejecutables. La seguridad de la ejecución de código administrado (incluidos los ensamblados MSIL, las imágenes NGen y el código no administrado) se refuerza mediante la selección aleatoria del diseño del espacio de direcciones (ASLR). Los ensamblados firmados con nombre seguro ya no necesitan comprobar sus firmas en tiempo de carga siempre que sean de plena confianza y se carguen en dominios de aplicación de plena confianza. Este cambio elimina las comprobaciones redundantes y mejora el rendimiento de inicio de las aplicaciones que tienen ensamblados firmados, pero que no están instalados en la caché global de ensamblados (GAC). Las aplicaciones iniciadas desde recursos compartidos de red tienen el mismo comportamiento que los ejecutables no administrados y funcionan en plena confianza en lugar de confianza parcial. Ahora se omite el atributo StringFreezingAttribute. Este atributo se usó para crear imágenes nativas mediante el generador de imágenes nativas (Ngen.exe). El inliner del compilador Just-In-Time (JIT) se ha mejorado significativamente para generar código de mejor calidad. Sin embargo, cambiar el inliner tiene un impacto en las aplicaciones que tienen clases de las que se crean instancias con constructores que usan el valor de enumeración TypeAttributes.BeforeFieldInit. Se garantiza que la inicialización estática de estos tipos se produce a la vez antes de que se tenga acceso a cualquiera de los campos estáticos, pero no antes de invocar un método estático o constructor de instancia. La hora exacta en que se invoca el constructor de clase puede ser diferente en .NET Framework versión 3.5 y 3.5 SP1. Otros cambios del compilador JIT incluyen cambios en los errores de redondeo de punto flotante y los cambios en el momento de los finalizadores. No se necesitan modificaciones. |
ADO.NET
Métodos CanConvertToString en clases de serializador de valor Los métodos CanConvertToString de las clases de serializador de valor del espacio de nombres System.Windows.Converters inician una excepción ArgumentException en lugar de devolver false. Los métodos System.Data.SqlClient.SQLDataReader.GetString y oth er Get inician una excepción InvalidCastException si los datos no se pueden convertir en el tipo que se solicita. Los mensajes ahora incluyen los tipos, como: "No se puede convertir el objeto de tipo 'System.Decimal' al tipo 'System.String'". No se necesitan modificaciones. |
SQLDataReader.GetString en columnas UDT Al llamar al método SQLDataReader.GetString en las columnas tipo definido por el usuario (UDT), ahora se produce una excepción InvalidCastException en lugar del mensaje de error "La conversión no se admite de Byte[] a String". No se necesitan modificaciones. |
C#
Las consultas en colecciones no genéricas ahora usan la semántica de conversión estándar de C#. En las expresiones de consulta LINQ sobre colecciones no genéricas como System.Collections.ArrayList , el compilador vuelve a escribir la cláusula from de la consulta para incluir una llamada al operador Cast<T> . Convertir<T> convierte todos los tipos de elementos en el tipo especificado en la cláusula from de la consulta. Además, en la versión de lanzamiento original de Visual C# 2008, el operador Cast<T> también realiza algunas conversiones de tipos de valor y conversiones definidas por el usuario. Sin embargo, estas conversiones se realizan mediante la clase System.Convert en lugar de la semántica estándar de C#. Estas conversiones también causan problemas de rendimiento significativos en determinados escenarios. En Visual C# 2008 SP1, el operador Cast<T> se modifica para iniciar una excepción InvalidCastException para el tipo de valor numérico y las conversiones definidas por el usuario. Este cambio elimina la semántica de conversión de C# no estándar y el problema de rendimiento. Este cambio se muestra en el ejemplo siguiente.
Modificaciones sugeridas: si tiene código que realiza consultas LINQ en colecciones no genéricas y ese código produce ahora una excepción, cambie el tipo de la expresión de consulta para que coincida con el tipo de los elementos de la colección que está consultando. Si necesita realizar una conversión de tipo de valor o definida por el usuario en los elementos, puede hacerlo mientras ejecuta la consulta, como se muestra en el ejemplo siguiente:
|
ASP.NET, IIS
Modo integrado de IIS En el modo de integración para Internet Information Services (IIS) 7.0, el método HttpServerUtility.TransferRequest usa incorrectamente el método HTTPResponse.End para detener la solicitud primaria. Esto produce una excepción ThreadAbortException , lo que puede afectar al rendimiento para terminar la ejecución de una respuesta. En .NET Framework 3.5 SP1, el método TransferRequest finaliza ahora la solicitud primaria mediante el método HttpApplication.CompleteRequest. Esto también finaliza correctamente la solicitud actual transfiriendo el control al controlador de eventos HttpApplication.EndRequest sin producir una excepción. Modificaciones sugeridas: si tiene código de control de errores que usa el método TransferRequest para determinar si se produjo threadAbortException , puede quitar ese código del bloque catch. (Por último, los bloques seguirán ejecutándose). |
Autenticación integrada de Windows Un cambio de seguridad afecta a la forma en que system.Net.HttpWebRequest , System.Net.HttpListener , System.Net.Security.NegotiateStream controla los autenticación de Windows integrados y las clases relacionadas del espacio de nombres System.Net. Este cambio puede afectar a los servidores web y las aplicaciones cliente que están configuradas para usar autenticación de Windows integradas. El proceso de autenticación de Microsoft Windows NT LAN Manager (NTLM) usado con autenticación de Windows integrado incluye un desafío emitido por el equipo de destino que se envía de vuelta al equipo cliente. Cuando un equipo recibe un desafío que generó, se producirá un error en la autenticación a menos que la conexión sea una conexión de bucle invertido (por ejemplo, dirección IPv4 127.0.0.1). La clase HttpWebRequest ahora especifica de forma predeterminada el nombre de host usado en la dirección URL de la solicitud en el nombre de entidad de seguridad de servicio (SPN) usado en el proceso de autenticación NTLM. Modificaciones sugeridas: puede proporcionar un SPN personalizado que se usará durante la autenticación en un diccionario de cadenas indizada por el URI. Este diccionario se obtiene con la propiedad System.Net.AuthenticationManager.CustomTargetNameDictionary. También puede agregar la siguiente configuración del Registro para asignar nombres a la conexión de bucle invertido:
|
CDOSYS Las clases del espacio de nombres System.Web.Mail se basan en objetos de datos de colaboración para componentes de Windows 2000, que no estarán disponibles en la próxima versión de Windows (Windows 7). Como resultado, el uso de estas clases en Windows 7 producirá una excepción PlatformNotSupportedException . Modificaciones sugeridas: System.Web.Mail ha quedado en desuso en .NET Framework versión 2.0. Use la compatibilidad de correo en el espacio de nombres System.Net.Mail en su lugar. |
ASP.NET validaciones de solicitudes ASP.NET validación de solicitudes ahora incluye la comprobación del corchete angular izquierdo y la secuencia de caracteres de signo de interrogación: Modificaciones suggested: el impacto de este cambio debe ser mínimo porque normalmente no hay ninguna razón para que se incluya un comentario XML en la cadena de consulta de la variable de cookie. |
Validaciones de direcciones URL ASP.NET ahora valida partes de la dirección URL cuando se accede desde una página de ASP.NET. Sin embargo, cuando se usa la reescritura de direcciones URL, es posible tener acceso a la versión anterior de la dirección URL en la página con la propiedad Request.RawUrl. Modificaciones sugeridas: deshabilite la validación en una página, si es necesario. |
Estados de sesión Se espera que los proveedores de estado de sesión implementen todos los miembros definidos en la clase System.Web.SessionState.SessionStateStoreProviderBase, incluido el método CreateUninitializedItem. Sin embargo, solo se llamó a este método cuando el sitio usaba un estado de sesión sin cookies. Los desarrolladores que no usaron un estado de sesión sin cookies no tenían que implementar CreateUninitializedItem en un proveedor personalizado. Con el lanzamiento de .NET Framework 3.5 SP1, ahora también se puede llamar al método CreateUninitializedItem en determinadas circunstancias cuando se usa un estado de sesión cookied. Modificaciones sugeridas: implemente CreateUninitializedItem en proveedores personalizados. Determine si ya existe un elemento "activo" para el identificador de sesión especificado. Si no existe un elemento, los proveedores deben crear un elemento para el identificador de sesión. |
Codificación de direcciones URL ASP.NET ahora expande la codificación url de los encabezados HTTP salientes para incluir el carácter de eliminación (7F) y todos los caracteres de control ASCII (excepto la pestaña horizontal). Modificaciones sugeridas: si es necesario, puede desactivar el comportamiento de codificación de encabezado predeterminado de la siguiente manera:
|
DefaultHTTPHandler en IIS Aunque la clase System.Web.DefaultHTTPHandler para las aplicaciones en modo integrado se convirtió en un módulo obsoleto en IIS 7.0, todavía era posible usar. Ahora produce una excepción PlatformNotSupported . Modificaciones sugeridas: cambie la configuración de la aplicación para que funcione correctamente en modo integrado. |
Coherencias de formato de número de cliente y servidor El comportamiento de formato de la función Number.localeFormat (se ejecuta en el cliente) ahora se ajusta al método String.Format (se ejecuta en el servidor). Por ejemplo, el código siguiente devuelve
Antes de .NET Framework 3.5 SP1, el código siguiente devolvería
Ahora, localeFormat devuelve No se necesitan modificaciones. |
ASP.NET campos ocultos Los campos de ASP.NET ocultos, como VIEWSTATE, ahora se representan en la parte superior de antes Modificaciones sugeridas: Necesito, puede desactivar este comportamiento estableciendo el nuevo atributo renderAllHiddenFieldsAtTopOfForm en false: El valor predeterminado es true. |
Windows Presentation Foundation (WPF)
Las clases BitmapEffect están obsoletas La clase System.Windows.Media.Effects.BitmapEffect y sus clases derivadas (BevelBitmapEffect, BitmapEffectGroup, BlurBitmapEffect, DropShadowBitmapEffect, EmbossBitmapEffect y OuterGlowBitmapEffect), ahora están obsoletas. Modificaciones sugeridas: deje de usar las clases BitmapEffect y derivadas heredadas y, en su lugar, use las nuevas clases derivadas de Effect:BlurEffect, DropShadowEffect y ShaderEffect. También puede crear sus propios efectos derivando de ShaderEffect. |
Cambio del nombre del ensamblado Se ha cambiado el nombre del ensamblado que contiene la capa de representación principal de WPF de milcore.dll a wpfgfx_v0300.dll. Este ensamblado nunca ha tenido ninguna API pública. No se necesitan modificaciones. |
Comportamiento del hipervínculo Si el valor de la propiedad Hyperlink.NavigateUri cambia entre el momento en que el usuario mantiene el cursor del mouse sobre un hipervínculo y la hora en que el usuario hace clic en ese hipervínculo, la navegación se producirá mediante el URI obtenido cuando el cursor mantenga el puntero sobre el hipervínculo. No se necesitan modificaciones. |
Internet Explorer en modo protegido en Windows Vista Cuando Internet Explorer está en modo protegido en Windows Vista, los cuadros de diálogo modales de la función de alerta DHTML () y los controles ActiveX hospedados en HTML se bloquean en lugar de mostrarse. Además, cuando el control WebBrowser o el control Frame que hospeda el CÓDIGO HTML se encuentra en una aplicación del explorador XMAL (XBAP) y XBAP se carga entre dominios en una página HTML, se produce una excepción. No se necesitan modificaciones. |
Métodos CanConvertToString en las clases Value Serializer Los métodos CanConvertToString de las clases de serializador de valores de los espacios de nombres System.Windows.Media.Converters y System.Windows.Media.Media3D.Converters inician una excepción ArgumentException en lugar de devolver false. No se necesitan modificaciones. |
Windows Communication Foundation (WCF) y Windows Workflow Foundation (WF)
Coincidencia de esquemas El esquema de coincidencia de esquemas que usan las clases UriTemplate y UriTemplateTable se ha relajado para aceptar direcciones base con esquemas distintos de HTTP. Ahora ninguna de estas clases usa el esquema o el número de puerto al hacer coincidir los URI candidatos con las plantillas. Se ha agregado compatibilidad con plantillas para barras diagonales finales y valores predeterminados. No se necesitan modificaciones. |
Mejoras de seguridad para la autenticación Cuando un servicio se ejecuta en una cuenta de usuario con seguridad en modo mixto, endPointIdentity debe tener una identidad de nombre principal de usuario (UPN). Esto no era necesario con versiones anteriores de WCF. Modificaciones sugeridas: cuando un cliente está establecido para usar la configuración SecurityMode.TransportWithMessageCredential (mediante autenticación de Windows, autenticación UPN o autenticación de huella digital), cree una instancia de la clase EndPointAddress con una identidad UPN y proporcione código personalizado para controlar cualquier comprobación de huella digital. |
Compatibilidad de confianza parcial para el registro de eventos La confianza parcial ahora admite el registro de eventos limitado. Solo los errores de activación del servicio, los errores de seguimiento y los errores de registro se registran en el registro de eventos. Para evitar escribir mensajes excesivos en el registro de eventos, el número máximo de eventos que puede registrar un proceso es 5. No se necesitan modificaciones. |
Disponibilidad de RemoteEndpointMessageProperty El acceso a una instancia de la clase RemoteEndpointMessageProperty cuando se usa HTTP hospedado en IIS depende de tener una solicitud activa actualmente. Por lo tanto, no se puede obtener una vez completada la solicitud (por ejemplo, al realizar una recepción unidireccional). No se necesitan modificaciones. |
Nota: Para solucionar problemas importantes que eran críticos para algunas aplicaciones, Microsoft planea proporcionar una actualización a NET Framework 3.5 SP1 que se puede incluir en una Windows Update importante. Encontrará más información sobre esta actualización en la página de descarga de .NET Framework 3.5 SP1 en el Centro de descarga de Microsoft.