Paquete acumulativo de revisiones 2996568 para el.NET Framework 4.5, 4.5.1 y 4.5.2 en Vista SP2, Windows Server 2008 Service Pack 2, Service Pack 1 de Windows 7 y Windows Server 2008 R2 SP1

Problema 1

Este hotfix resuelve los siguientes dos problemas de subprocesamiento de System.IO.Packaging cuando utilizas el 4.5 de.NET Framework, el.NET Framework 4.5.1 o el.NET Framework 4.5.2.

• Puede producir un interbloqueo cuando utiliza paquetes grandes en subprocesos separados. System.IO.Packaging utiliza IsolatedStorage para paquetes mayores de 10 megabytes (MB). Cuando dos o más subprocesos utilizan paquetes grandes, puede producirse un interbloqueo, incluso si los paquetes son independientes. El interbloqueo implica dos subprocesos. Uno está esperando en IsolatedStorageFile.Lock , mientras que el otro está esperando en otro método de la clase IsoloatedStorageFile . Este problema se corrige mediante la adición de sincronización a System.IO.Packaging para evitar el problema en IsolatedStorageFile.

• Pueden producir excepciones al recuperar PackageProperties de paquetes que se abren en subprocesos separados, incluso si los paquetes son independientes. Las pilas de llamadas más comunes que surgen de esto son los siguientes:System.Xml.XmlException: Unrecognized root element in Core Properties part. Line 2, position 2. atMS.Internal.IO.Packaging.PartBasedPackageProperties.ParseCorePropertyPart(PackagePart part) at
  System.IO.Packaging.Package.get_PackageProperties()
  System.ArgumentOutOfRangeException: Specified argument was out of the range of valid values. Parameter name: id atMS.Internal.IO.Packaging.PartBasedPackageProperties.ParseCorePropertyPart(PackagePart part) at
  System.IO.Packaging.Package.get_PackageProperties()
  Este problema está causado por la contención de un recurso compartido interno y se resuelve asignando a cada paquete una copia de ese recurso.

Problema 2

Una aplicación de Windows Presentation Foundation (WPF) puede utilizar una gran cantidad de memoria cuando recibe muchas solicitudes para el servicio de UIAutomation . La memoria pertenece a los objetos del espacio de nombres System.Threading . Esto incluye System.Threading.CancellationTokenSource, System.Threading.TimerQueueTimer, System.Threading.Timery varias otras clases relacionadas.

Éstos son los objetos que se asignan en nombre de WPF cuando WPF recibe una solicitud para la actividad de UIAutomation . Finalmente se lanzan hasta el límite de tiempo de espera para la solicitud caduca (normalmente tres minutos). Si las solicitudes llegan rápidamente, la aplicación parece estar perdiendo memoria o utilizar más memoria de lo que es razonable (tanto como 500 MB).

Este problema se resuelve mediante la liberación de los objetos cuando se complete la solicitud, en lugar de esperar el plazo de tiempo de espera.

Problema 3

En una aplicación WPF, cuando escribe texto utilizando el Editor coreano de método de entrada (IME), la propiedad Text de un ComboBox de editable no cambia correctamente en algunos casos.

Este problema puede presentar diversos síntomas, y que depende de cómo la aplicación (o el autor del control) ha configurado el control ComboBox. Por ejemplo:

• Después de que escriba y ficha ausente (o desplazar el enfoque a otro control), el texto mostrado del control ComboBox se revierte a una cadena vacía o el valor que tenía antes de la escritura.

• La característica TextSearch de ComboBox se comporta incorrectamente. No coincide con el prefijo que se ha introducido o coincide con un elemento no relacionado.

Este problema se resuelve mediante la modificación de la lógica para dar cabida a la temporización del IME coreano que difiere ligeramente de otros IME.

Problema 4

Después de utilizar un dispositivo táctil para realizar una operación de arrastrar y colocar en una aplicación WPF, se omite el siguiente movimiento táctil.

Este problema se resuelve al restaurar el estado interno del controlador de entrada táctil una vez completada la operación de arrastrar y colocar. De esta manera, calcula la posición del siguiente movimiento táctil correctamente.

Problema 5

Una nueva implementación de AuthenticationManager también puede habilitarse para obtener un rendimiento significativo cuando se trabaja con personalizado IAuthenticationModules.

Nota: Principales riesgos de seguridad aparecen si el código no está diseñado para ser seguro para subprocesos. El cambio de comportamiento importantes se encuentra en el métodos PreAuthenticate y autenticar . Anteriormente se garantiza que el código se estaba ejecutando en serie (se ha tomado un bloqueo global). En la nueva implementación, sin bloqueo, y el código de cliente debe garantizar la seguridad para subprocesos.
Además, con la nueva implementación, el tamaño de la caché de PrefixLookup puede controlarse a través del registro.

Las siguientes claves del registro pueden utilizarse para habilitar y configurar la longitud máxima de PrefixLookup:

• Configuración global[HKEY_LOCAL_MACHINE\SOFTWARE[\Wow6432Node]\Microsoft\.NETFramework\v4.0.30319]"System.Net.AuthenticationManager.HighPerformance"=dword:00000001
  "System.Net.AuthenticationManager.PrefixLookupMaxCount"=dword:00010000
  

• Configuración de la aplicación local[HKEY_LOCAL_MACHINE\SOFTWARE[\Wow6432Node]\Microsoft\.NETFramework\v4.0.30319\System.Net.AuthenticationManager.HighPerformance]"c:\myapp\myapp.exe"=dword:00000001
  [HKEY_LOCAL_MACHINE\SOFTWARE[\Wow6432Node]\Microsoft\.NETFramework\v4.0.30319\System.Net.AuthenticationManager.PrefixLookupMaxCount]
  "c:\myapp\myapp.exe"=dword:00010000
  

Configuración global tiene prioridad sobre la configuración de la aplicación local. Configuración de la aplicación global y local se puede combinar. PrefixLookupMaxCount no se verán afectados si se establece el valor de alto rendimiento de aplicación global o local en DWORD 1.

Problema 6

Suponga que ejecuta una aplicación que se basa la 4.5 de.NET Framework, el.NET Framework 4.5.1 o el.NET Framework 4.5.2. La aplicación produce una excepción en un método administrado que se ha llamado desde código nativo y se pasó una interfaz COM por referencia. En esta situación, la aplicación puede bloquearse.

Por ejemplo: una aplicación escrita en VB6 llama a una DLL C#. Si la aplicación y el archivo DLL se compilan en modo de lanzamiento, cuando se produce una excepción en el código C#, se produce una infracción de acceso y se bloquea la aplicación.

Problema 7

Cuando los proyectos de flujo de trabajo basado en XAML toma más tiempo que el tiempo de concesión predeterminado (cinco minutos) de los objetos remotos que definen las tareas para generar el código XAML, recibirá un mensaje de error similar al siguiente:

Después de aplicar este hotfix, puede definir su propio tiempo de concesión (en minutos) mediante la definición de la variable de entorno denominada XamlBuildTaskRemotingLeaseLifetimeInMinutes.

Para establecer la variable de entorno en un archivo de proyecto de MSBuild, deberá incluir la siguiente información en el archivo de proyecto:<Project ...> <UsingTask TaskName="MySetEnv" TaskFactory="CodeTaskFactory" AssemblyFile="$(MSBuildToolsPath)\Microsoft.Build.Tasks.v4.0.dll" >
<ParameterGroup>
<Name Required="true" />
<Value Required="false" />
</ParameterGroup>
<Task>
<Code Type="Fragment" Language="cs">System.Environment.SetEnvironmentVariable(Name, Value);</Code>
</Task>
</UsingTask>
...
...
<Target Name="BeforeBuild">
<MySetEnv Name="XamlBuildTaskRemotingLeaseLifetimeInMinutes" Value="1440" />
</Target>
<Target Name="AfterBuild">
<MySetEnv Name="XamlBuildTaskRemotingLeaseLifetimeInMinutes" Value="" />
</Target>
</Project>
El nombre de tarea en este ejemplo es MySetEnv. Puede establecerse en cualquier cadena que es válido para nombres de tareas. Este ejemplo establece el tiempo de concesión a 1.440 minutos (un día) antes de la creación del proyecto y establece en null después de la compilación. Si hay varios proyectos que necesita para ampliar el tiempo de concesión, cada proyecto necesita esta configuración.

Problema 8

Cuando se utiliza la devolución de AJAX en una página, a veces la devolución de datos se redirige a otra dirección URL. Puede obtener el RedirectLocation en un HttpModule a través de HttpContext.Items["System.Web.UI.PageRequestManager:AsyncPostBackRedirectLocation"].