Cet article décrit le correctif 3088958 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 les problèmes résolus dans le correctif cumulatif, reportez-vous à la section «problèmes résolus dans ce correctif cumulatif».
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.
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, frais généralement encourus pour la prise en charge des appels peuvent être annulés si un technicien du support technique Microsoft détermine qu’une mise à jour spécifique résoudra votre problème. Les coûts habituels du support technique s’appliqueront aux questions supplémentaires et aux problèmes qui ne relèvent de la mise à jour spécifique en question.
Remarque : Pour vérifier la version de mise à jour de correctif logiciel, vérifiez la valeur du mot clé version pour déterminer la version installée. Pour être à compatibilité ascendante, vous pouvez vérifier une valeur qui est supérieure ou égale à la valeur qui est répertoriée dans le tableau suivant.
|
Version de correctif cumulatif |
Valeur de la version DWORD |
|---|---|
|
Correctif cumulatif 3088958 pour le.NET Framework 4.5 et les versions ultérieures du.NET Framework |
379991 |
Pour plus d’informations sur la façon de déterminer les versions de.NET Framework, consultez Comment : déterminer lequel.NET Framework Versions sont installés.
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.
Problèmes résolus dans ce correctif cumulatif
Problème 1
Il s’agit d’une mise à jour pour prendre en charge le nouveau symbole Géorgien Lari. Le pays de Géorgie a introduit un nouveau symbole de devise pour le Lari, mais le nom de la devise n’est pas modifié. Le nouveau symbole de devise a également été ajouté à la norme Unicode. Cette mise à jour permet de s’assurer que le symbole monétaire correct est affiché par le.NET Framework en fonction des paramètres régionaux du système.
Problème 2
Ce correctif cumulatif résout un problème avec les applications de notions de base sur WPF (Windows Presentation) tactile qui sont en cours d’exécution dans le même processus mais ciblant deux différentes versions du.NET Framework. Un exemple de ce problème est deux VSTO compléments écrits dans WPF, mais ciblé aux différentes infrastructures de .NET côte-à-côte. Les utilisateurs dans ce scénario pourraient voir le comportement de touche étrange ou tombe en panne à différents points pendant l’exécution du programme.
Le correctif permet de s’assurer que la bonne DLL sont chargées et accessibles dans ces scénarios, l’arrêt de tous les problèmes avec le comportement de touche ou programme se bloque.
Remarque Si vous utilisez le.NET Framework 3.5 Service Pack 2 sur votre ordinateur, installez le correctif correspondant à votre version résoudre ce problème.
Problème 3
Si vous avez un site Web ASP.NET qui s’exécute sur une version 32 bits de la 4.6 de.NET Framework ou la version AMD64 de la plate-forme.NET Framework 4.6 avec RyuJit désactivé, vous pouvez rencontrer w3wp incident car ThreadAbortException non gérée.
Lorsque l’incident se produit, vous pouvez voir le journal suivant dans le journal des événements Windows :
Une exception non gérée s’est produite et le processus a été arrêté.
ID de l’application : [ApplicationID]
ID de processus : [ProcessID]
Exceptions : System.Threading.ThreadAbortException
Message : Le Thread a été abandonné.
StackTrace : À System.Web.HttpRuntime.ProcessRequestNotificationPrivate (IIS7WorkerRequest wr, HttpContext context)
à System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper (IntPtr rootedObjectsPointer, IntPtr nativeRequestContext, IntPtr moduleData, indicateurs de Int32)
à System.Web.Hosting.PipelineRuntime.ProcessRequestNotification (IntPtr rootedObjectsPointer, IntPtr nativeRequestContext, IntPtr moduleData, indicateurs de Int32)
Problème 4
Supposons que vous disposez d’un client WCF se connectant au service WCF à l’aide du Service de routage de WCF. Si le service fin déclenche une exception inattendue qui n’est pas un type d’exception FaultException ou les modifications de configuration, WCF le Service de routage ne peut pas router les demandes suivantes au service de fin.
Lorsque ce problème se produit, vous recevez l’exception suivante :
System.ServiceModel.ProtocolException : Ce canal n’est plus utilisable pour envoyer des messages car la session de sortie a été fermée automatiquement en raison d’un arrêt exécutée par le serveur. Désactivez la fermeture automatique en définissant le DispatchRuntime.AutomaticInputSessionShutdown sur false ou envisagez de modifier le protocole d’arrêt avec le serveur distant.
Informations de trace de pile :
at System.ServiceModel.Channels.ServiceChannel.PrepareCall(ProxyOperationRuntime operation, Boolean oneway, ProxyRpc& rpc)at System.ServiceModel.Channels.ServiceChannel.SendAsyncResult.Begin()
at System.ServiceModel.Channels.ServiceChannel.BeginCall(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, TimeSpan timeout, AsyncCallback callback, Object asyncState)
at System.ServiceModel.Channels.ServiceChannelProxy.InvokeBeginService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at System.ServiceModel.Routing.IRequestReplyRouter.BeginProcessRequest(Message message, AsyncCallback callback, Object state)
at System.ServiceModel.Routing.ClientFactory.RequestReplyClient.OnBeginOperation(Message message, AsyncCallback callback, Object state)
at System.ServiceModel.Routing.ClientFactory.RoutingClientBase`1.OperationAsyncResult.CallOperation()
at System.ServiceModel.Routing.ClientFactory.RoutingClientBase`1.OperationAsyncResult..ctor(RoutingClientBase`1 parent, Message requestMessage, Transaction transaction, AsyncCallback callback, Object state)
at System.ServiceModel.Routing.ClientFactory.RoutingClientBase`1.BeginOperation(Message message, Transaction transaction, AsyncCallback callback, Object state)
at System.ServiceModel.Routing.ProcessRequestAsyncResult`1.StartProcessing()
at System.ServiceModel.Routing.ProcessRequestAsyncResult`1..ctor(RoutingService service, Message message, AsyncCallback callback, Object state)
at System.ServiceModel.Routing.RoutingService.BeginProcessRequest[TContract](Message message, AsyncCallback callback, Object state)
at System.ServiceModel.Routing.RoutingService.System.ServiceModel.Routing.IRequestReplyRouter.BeginProcessRequest(Message message, AsyncCallback callback, Object state)
at AsyncInvokeBeginBeginProcessRequest(Object , Object[] , AsyncCallback , Object )
at System.ServiceModel.Dispatcher.AsyncMethodInvoker.InvokeBegin(Object instance, Object[] inputs, AsyncCallback callback, Object state)
