Correctif cumulatif 3009698 (programme d’installation Web) pour le.NET Framework 4.5, 4.5.1 et 4.5.2 sur Windows Vista SP2, Windows 7 SP1, Windows 8, Windows 8.1, Windows Server 2008 SP2, Windows Server 2008 R2 SP1, Windows Server 2012 et Windows Server 2012 R2

Cet article décrit le correctif 3009698 disponible pour le point 4.5.2 de Microsoft.NET Framework et le.NET Framework 4.5.1 le 4.5 de.NET Framework. Pour plus d’informations sur le correctif logiciel cumulatif résout les problèmes, consultez la section «problèmes liés à ce correctif logiciel cumulatif résout».

Le programme d’installation web est un petit paquet (inférieurs à un mégaoctet) qui détermine automatiquement et les télécharge uniquement les composants qui sont applicables pour une plate-forme particulière.

Cette mise à jour regroupe les différents packages pour les différents produits et plates-formes suivantes.

Description

Numéro d'article de la Base de connaissances

Le.NET Framework 4.5, 4.5.1 et 4.5.2 sur Windows Vista SP2, Windows Server 2008 SP2, Windows 7 SP1 et Windows Server 2008 R2 SP1

3011114

Le.NET Framework 4.5, 4.5.1 et 4.5.2 sur Windows 8 et Windows Server 2012

3011112

Le.NET Framework 4.5.1 et 4.5.2 sur 8.1 de Windows et de Windows Server 2012 R2

3011110


Résolution

Un correctif pris en charge est désormais disponible auprès de Microsoft. Toutefois, il est conçu pour résoudre uniquement le problème décrit dans cet article. Il s’applique uniquement aux systèmes rencontrant ce problème spécifique.

Pour résoudre ce problème, contactez les Services de Support technique Microsoft pour obtenir le correctif. Pour obtenir une liste complète des numéros de téléphone des Services de Support technique Microsoft et des informations relatives aux frais de support technique, visitez le site Web Microsoft suivant :

http://support.microsoft.com/contactus/?ws=supportRemarque Dans des cas particuliers, des frais généralement encourus pour les appels au support technique peuvent être annulés si un technicien du support technique Microsoft détermine qu'une mise à jour spécifique peut résoudre votre problème. Les coûts habituels du support technique s’appliqueront aux autres questions et problèmes qui ne relèvent pas de la mise à jour spécifique en question.

Plus d'informations

Conditions préalables

Pour appliquer ce correctif, vous devez disposer le point 4.5.2 de.NET Framework, le.NET Framework 4.5.1 ou le 4.5 de.NET Framework installée.

Nécessite un redémarrage

Vous devez redémarrer l’ordinateur après avoir appliqué ce correctif logiciel si tous les fichiers affectés sont utilisés. Nous vous recommandons de fermer toutes les applications basées sur le.NET Framework avant d’appliquer ce correctif.

Informations de remplacement du correctif

Ce correctif logiciel ne remplace pas un package correctif publié précédemment.











Ce correctif cumulatif résout les problèmes

Problème 1

Dans le.NET Framework 4.5 navigation au clavier dans un contrôle TreeView de WPF ne fonctionne pas correctement lorsqu’un TreeViewItem contient un élément pouvant être actif, par exemple un bouton, une case à cocherou une Zone de texte. En appuyant sur la flèche haut ou flèche bas peut viser à l’élément incorrect ou ne peut pas modifier le focus du tout.

Le correctif résout ce problème pour que la flèche haut et flèche bas toujours modifier le focus à l’élément correct.

Problème 2

Lorsque vous appelez GlyphRun.InkBoundingBox() ou l’une de ses dépendances, telles que FormattedText.Extent , dans une application WPF, les valeurs de retour sont légèrement plus volumineux dans le 4.5 de.NET Framework que dans.NET Framework 4.0. Le de.NET Framework 4.0 présentait un bogue qui parfois s’est produite dans le texte qui n’a pas dessiné (en fonction de la police, la taille de police et des caractères spécifiques). Le bogue a été corrigé dans le 4.5 de.NET Framework à l’agrandissement de l’encre cadre légèrement.

Ce correctif logiciel ajoute un indicateur de configuration pour choisir de ne pas le correctif. Une application qui choisit les aura les mêmes valeurs de retour dans le 4.0 de.NET Framework, mais il peut rencontrer également le bogue « disparaître le texte ».

Pour refuser le correctif, ajoutez la clé suivante à la section appSettings du fichier de configuration de l’application :<add key="IncludeAllInkInBoundingBox" value="false"/> Problème 3

Considérez le scénario suivant :

Dans ce scénario, la page Web du client ne fonctionne pas. Par exemple, rien ne se passe lorsque vous cliquez sur un bouton qui est censé pour déclencher un rappel.

Problème 4

Supposons que vous créez une classe System.Workflow.Activities.StateMachineWorkflowActivity , ainsi qu’une propriété d’activités qui spécifie une liste de ActivitiesCollection . La liste contient de nombreuses activités (par exemple, les activités de 300 ou plus) qui sont l’état et les activités de l’état non.

Dans ce cas, transitions aux activités de l’état qui approchent la fin de la liste ActivitiesCollection prennent beaucoup plus de temps que les transitions aux activités de l’état qui se trouvent au début de la liste.

Ce correctif supprime des parcours de liste ActivitiesCollection inutiles lors de la recherche de l’activité d’état de la cible par son nom au cours d’une transition d’état. Par conséquent, moins de temps est nécessaire pour effectuer la transition pour les activités d’état vers la fin de la liste de ActivitiesCollection .

Problème 5

Supposons que les compteurs de performance WCF sont activées. Toutefois, certains noms d’instance sont ramenés, car ils sont plus de 64 caractères. En outre, deux noms d’instance raccourcie peuvent être le même. Dans ce scénario, WCF ne crée pas les instances de compteur comme prévu.

Pour activer ce correctif, ajoutez la ligne suivante appSettings dans votre fichier de configuration :<appSettings><add key=" wcf:ensureUniquePerformanceCounterInstanceNames " value="true" />
</appSettings>
Une fois ce paramètre activé, WCF détectera si deux noms d’instance sont en conflit et ajoute un hachage hexadécimal à huit chiffres à la fin de l’un des noms. Ainsi, les deux instances est créé avec succès.

Problème 6

Supposons que vous utilisez WCF comme un client de milieu de gamme pour un site Web ou un service web pour communiquer avec un service d’équilibrage de charge back-end sur HTTP. En outre, un des hôtes du back-end est en état d’échec qui renvoie des réponses HTTP avec un code d’état « 500 ».

Dans ce cas, la connexion à l’hôte principal défaillant persiste dans le pool de connexions WCF ChannelFactory , car elle retourne des réponses HTTP valides et entraîne un taux élevé de demandes ayant échoué. Il n’y a aucun mécanisme disponible pour supprimer une connexion à un hôte défaillant qui pourrait conduire à l’échec de requêtes frontales.

Pour activer ce correctif, ajoutez la ligne suivante appSettings dans votre fichier de configuration : <appSettings> <add key="wcf:httpTransportBinding:useUniqueConnectionPoolPerFactory" value="true"/>
</appSettings>
Une fois ce correctif logiciel est activé, chaque instance de ChannelFactory qui est créé et qui utilise le transport HTTP aura un pool de connexions distinct. Cela permet aux développeurs de partitionner leurs connexions en pools distincts par le biais de l’instanciation de plusieurs objets de ChannelFactory . De cette manière, une connexion à un hôte défaillant peut être supprimée à la fermeture de l’instance de ChannelFactory qui est associé à la connexion à l’hôte défaillant. Lorsqu’une instance de ChannelFactory est fermée, les connexions dans le pool est inutile à être fermées immédiatement car ils sont régis par le comportement de regroupement de la classe ServicePointManager . Il est important de définir une valeur par défaut de faible délai d’inactivité si de nombreux objets ChannelFactory sont créé et fermé dans commande à éviter dans les nombreuses connexions inactives sont dans un état de fermeture en attente.

Problème 7

Supposons que vous souhaitez prendre en charge le grand nombre de téléchargements simultanés ou téléchargements à un service WCF qui expose un point de terminaison WebHttpBinding . Transferts de contenu de données de grande taille en utilisant le mode de transmission en continu (au lieu du mode de mise en mémoire tampon) entraîne le service à rencontrer des problèmes de performances, qu’un DispatcherSynchronizationBehavior est ajoutée.

Après avoir appliqué ce correctif, WCF utilise un traitement asynchrone qui augmente considérablement les performances de plusieurs téléchargements simultanés et les téléchargements.

Ce correctif est activé lorsque la propriété AsynchronousSendEnabled de l' DispatcherSynchronizationBehavior a la valeur true. Pour le désactiver, supprimer la dispatcherSynchronizationBehavior, ou de définir explicitement la propriété AsynchronousSendEnabled sur false:<system.ServiceModel> <behaviors>
<endpointBehaviors>
<behavior name="MyEndpointBehavior">
<dispatcherSynchronization asynchronousSendEnabled="false" maxPendingReceives="5" />
</behavior>
</endpointBehaviors>
</behaviors>
</system.ServiceModel>
Problème 8

Supposons que vous appliquez la mise à jour des fuseaux horaires russes septembre 2014 (2998527 de mettre à jour) sur votre ordinateur. Lorsque vous avez une application qui utilise la classe TimeZoneInfo et du Microsoft.NET Framework, l’application peut calculer temps incorrecte. Pour plus d’informations, reportez-vous à la section 3012229 de la mise à jour .

Ce correctif corrige les recherches de décalage de fuseau horaire de base.

Problème 9

Supposons que vous disposez d’une application WPF qui ouvre une fenêtre dans la fenêtre principale. Lorsque vous redimensionnez la deuxième fenêtre, l’application se bloque et lève une exception de pointeur null.

Besoin d’aide ?

Développez vos compétences
Découvrez des formations
Accédez aux nouvelles fonctionnalités en avant-première
Rejoindre Microsoft Insider

Ces informations vous ont-elles été utiles ?

Nous vous remercions pour vos commentaires.

Merci pour vos commentaires. Il serait vraisemblablement utile pour vous de contacter l’un de nos agents du support Office.

×