Correctif cumulatif 2996568 pour le.NET Framework 4.5, 4.5.1 et 4.5.2 sur Vista SP2, Windows Server 2008 SP2, Windows 7 SP1 et Windows Server 2008 R2 SP1

Problème 1

Ce correctif résout les problèmes de threads deux suivants dans System.IO.Packaging lorsque vous utilisez le 4.5 de.NET Framework, le.NET Framework 4.5.1 ou le point 4.5.2 de.NET Framework.

• Un blocage peut se produire lorsque vous utilisez des packages volumineux sur des threads séparés. System.IO.Packaging utilise IsolatedStorage pour les packages qui sont supérieures à 10 mégaoctets (Mo). Lorsque deux threads ou plus utilisent les packages de grande taille, un blocage peut se produire, même si les lots sont indépendants. Le blocage implique les deux threads. Un est en attente de IsolatedStorageFile.Lock tandis que l’autre est en attente dans une autre méthode de la classe IsoloatedStorageFile . Ce problème est résolu par ajout de la synchronisation à System.IO.Packaging pour éviter le problème dans un IsolatedStorageFile.

• Les exceptions peuvent se produire lorsque vous récupérez PackageProperties à partir de packages qui sont ouverts sur des threads séparés, même si les lots sont indépendants. Les piles d’appels courants survenant à partir de ce sont les suivantes :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()
  Ce problème est dû à un conflit sur une ressource partagée d’interne et est résolu en donnant à chaque package une copie de la ressource.

Problème 2

Une application Windows Presentation Foundation (WPF) peut-être utiliser une grande quantité de mémoire lorsqu’il reçoit beaucoup de demandes pour le service UIAutomation . La mémoire appartient aux objets qui se trouvent dans l’espace de noms System.Threading . Ainsi, System.Threading.CancellationTokenSource, System.Threading.TimerQueueTimer, System.Threading.Timeret plusieurs autres classes connexes.

Il s’agit d’objets qui sont affectés au nom WPF lorsque WPF reçoit une demande pour l’activité de UIAutomation . Ils sont finalement publiées avant l’expiration de l’échéance du délai d’attente de la demande (trois minutes). Si les requêtes arrivent rapidement, l’application semble présenter une fuite de mémoire, ou à l’aide de plus de mémoire que ce qui est raisonnable (jusqu'à 500 Mo).

Ce problème est résolu en libérant les objets lorsque la demande est terminée, au lieu d’attendre l’échéance du délai d’attente.

Problème 3

Dans une application WPF, lorsque vous entrez du texte à l’aide de l’éditeur de méthode d’entrée coréen (IME, Internet Connection Firewall), la propriété Text d’un contrôle ComboBox de modifiable n'est pas modifiée correctement dans certains cas.

Ce problème peut présenter différents symptômes, et qui dépend de la façon dont l’application (ou l’auteur du contrôle) a configuré le contrôle ComboBox. Par exemple :

• Une fois que vous tapez et onglet absent (ou déplacez le focus vers un autre contrôle), le texte affiché du contrôle ComboBox rétablit la chaîne vide, ou la valeur qu’il avait avant la saisie.

• La fonction TextSearch du contrôle ComboBox se comporte correctement. Le préfixe a été saisi ne correspond pas, ou qu’il correspond à un élément indépendant.

Ce problème est résolu en modifiant la logique pour prendre en charge de la synchronisation de l’éditeur IME coréen qui diffère légèrement des autres éditeurs.

Problème 4

Après avoir utilisé une pression tactile pour effectuer une opération de glisser-déplacer dans une application WPF, le mouvement tactile suivant est ignoré.

Ce problème est résolu en restaurant l’état interne du Gestionnaire d’entrée tactile lors de l’opération de glisser-déplacer est terminée. De cette manière, il calcule la position du mouvement tactile suivant correctement.

Problème 5

Une nouvelle implémentation de la classe AuthenticationManager peut être éventuellement activée pour obtenir des performances lorsque vous travaillez avec personnalisé IAuthenticationModules.

Remarque Risques majeurs de sécurité s’affichent si le code n’est pas conçu pour être thread-safe. Les modifications majeures du comportement se trouve sur les méthodes PreAuthenticate et authentifier . Précédemment, il est garanti que le code est en cours d’exécution en série (un verrouillage global a été pris). Dans la nouvelle implémentation, aucun verrou n’est effectuée, et le code client doit garantir la sécurité des threads.
En outre, avec la nouvelle implémentation, la taille du cache de PrefixLookup peut être contrôlée par l’intermédiaire du Registre.

Les clés de Registre suivantes peuvent être utilisés pour activer et configurer la longueur maximale de PrefixLookup:

• Configuration globale[HKEY_LOCAL_MACHINE\SOFTWARE[\Wow6432Node]\Microsoft\.NETFramework\v4.0.30319]"System.Net.AuthenticationManager.HighPerformance"=dword:00000001
  "System.Net.AuthenticationManager.PrefixLookupMaxCount"=dword:00010000
  

• Configuration de l’application locale[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
  

Les paramètres globaux ont priorité sur les paramètres de l’application locale. Paramètres d’application globaux et locaux peuvent être mélangés. PrefixLookupMaxCount ne pas être affecté si l’application globale ou locale ultraperformante est défini sur DWORD 1.

Problème 6

Supposons que vous exécutez une application qui repose sur le 4.5 de.NET Framework, le.NET Framework 4.5.1 ou le point 4.5.2 de.NET Framework. L’application lève une exception dans une méthode managée qui a été appelée à partir de code natif et d’une interface COM passée par référence. Dans ce cas, l’application peut se bloquer.

Par exemple : une application qui est écrit dans VB6 appelle une DLL C#. Si l’application et la DLL sont compilés en mode release, lorsqu’une exception est levée dans le code C#, une violation d’accès se produit et l’application se bloque.

Problème 7

Lorsque les projets workflow basée sur XAML prennent plus de temps que la durée de bail par défaut (cinq minutes) des objets distants qui sont définies par les tâches pour générer le code XAML, vous recevez un message d’erreur semblable au suivant :

Après avoir appliqué ce correctif logiciel, vous pouvez définir votre propre durée (en minutes) en définissant la variable d’environnement nommée XamlBuildTaskRemotingLeaseLifetimeInMinutes.

Pour définir la variable d’environnement dans un fichier projet MSBuild, vous devez inclure les informations suivantes dans votre fichier projet :<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>
Le nom de la tâche dans cet exemple est MySetEnv. Elle peut être définie à n’importe quelle chaîne qui est valide pour les noms de tâche. Cet exemple définit la durée du bail à 1 440 minutes (1 jour) avant la génération du projet et lui affecte null après la génération. S’il existe plusieurs projets qui nécessite de prolonger la durée du bail, chaque projet a besoin de cette configuration.

Problème 8

Lorsque vous utilisez un postback AJAX dans une page, la publication (postback) est parfois redirigé vers une autre URL. Vous pouvez obtenir le RedirectLocation dans un HttpModule via HttpContext.Items["System.Web.UI.PageRequestManager:AsyncPostBackRedirectLocation"].