CORRECTIF : une fuite de mémoire se produit dans le VisualBasic.VsaEngine lorsque Création de plusieurs assemblys

IMPORTANT : Cet article est issu du système de traduction automatique mis au point par Microsoft (http://support.microsoft.com/gp/mtdetails). Un certain nombre d’articles obtenus par traduction automatique sont en effet mis à votre disposition en complément des articles traduits en langue française par des traducteurs professionnels. Cela vous permet d’avoir accès, dans votre propre langue, à l’ensemble des articles de la base de connaissances rédigés originellement en langue anglaise. Les articles traduits automatiquement ne sont pas toujours parfaits et peuvent comporter des erreurs de vocabulaire, de syntaxe ou de grammaire (probablement semblables aux erreurs que ferait une personne étrangère s’exprimant dans votre langue !). Néanmoins, mis à part ces imperfections, ces articles devraient suffire à vous orienter et à vous aider à résoudre votre problème. Microsoft s’efforce aussi continuellement de faire évoluer son système de traduction automatique.

La version anglaise de cet article est la suivante: 814483
Cet article a été archivé. Il est proposé « en l'état » et ne sera plus mis à jour.
Symptômes
Lorsque vous utilisez Visual Studio pour Applications (VSA) dans votre solution personnalisée et que vous compilez nouveau assemblys qui utilisent une instance de la VisualBasic.VsaEngine, vous pouvez constater une augmentation de mémoire pour le jeu de travail de processus chaque fois qu'un nouvel assembly est effectué. La mémoire ne peut pas être récupérée en la ordinateur hôte. Par conséquent, la mémoire est « divulguée » par l'espace de processus qui effectue la compilation.

Le problème ne se produit pas lorsque vous utilisez le moteur Microsoft JScript VSA.
Cause
Le problème est provoqué par une combinaison des trois problèmes plus petits. Ces problèmes sont liés à la capacité du moteur de Microsoft Visual Basic VSA à compiler les assemblys qui sont dans le processus ordinateur hôte. Les problèmes suivants ont été identifiés comme causes de la fuite :
  • Un COM callable wrapper (CCW) utilisé pendant le processus de compilation entre le Microsoft .NET Framework et le compilateur Visual Basic natif peut conservée en mémoire. Cela se produit même si l'objet est libéré correctement. Ce problème n'est pas spécifique à VSA. Ce problème peut être évité si vous utilisez le correctif est fourni et fermer est appelée sur le moteur avant que le moteur est lancé.
  • Lorsque des symboles sont apportées pour l'assembly, le fichier de base de données de programme (PDB) peut consommer mémoire pas immédiatement récupéré par le garbage collector. Si vous n'avez pas besoin de symboles pour le code compilé, vous pouvez éviter le problème. La valeur GenerateDebugInfo False avant que la méthode de compilation est appelée.
  • Le processus de compilation interne peut échouer libérer certaines poignées runtime langue courantes lors du traitement du code Visual Basic. Le nombre de handles sont divulguée dépend le code qui est compilé. Ce problème a été résolu par le correctif.
Résolution

Informations sur le service pack

Pour résoudre ce problème, procurez-vous le dernier service pack Visual Studio .NET. Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
837234 Liste des bogues corrigés dans Visual Studio .NET 2002 Service Pack 1

Informations sur le correctif

La version anglaise de ce correctif dispose les attributs de fichier (ou attributs de fichier version ultérieure) répertoriés dans le tableau suivant. Les dates et heures de ces fichiers sont exprimées en temps universel coordonné (UTC). Lorsque vous affichez les informations de fichier, il est convertie en heure locale. Pour connaître le décalage entre l'heure UTC et l'heure locale, utilisez l'onglet Fuseau horaire dans l'outil Date et heure du Panneau de configuration.
   Date         Time   Version         Size       File name   -----------------------------------------------------------------------   15-Feb-2003  00:25  5.50.4134.600   6,428,040  Vs70_qfem_q814483_en.exe

Statut
Microsoft a confirmé que c'est un problème dans les produits Microsoft répertoriés dans la section « S'applique à ». Ce problème a été corrigé dans Visual Studio .NET 2002 Service Pack 1.

Avertissement : Cet article a été traduit automatiquement.

Propriétés

ID d'article : 814483 - Dernière mise à jour : 01/07/2015 16:46:30 - Révision : 4.1

Microsoft Visual Studio .NET 2002 Professional Edition, Microsoft Visual Studio for Applications SDK 1.0

  • kbnosurvey kbarchive kbmt kbqfe kbhotfixserver kbvs2002sp1fix kbvs2002sp1sweep kbbug KB814483 KbMtfr
Commentaires