Erreur irrécupérable du moteur d’exécution lorsque vous obtenez le descripteur de sécurité d’une classe générique à partir d’un module d’image natif dans un environnement .NET Framework

Cet article vous aide à résoudre l’erreur irrécupérable du moteur d’exécution qui se produit lorsque vous obtenez le descripteur de sécurité d’une classe générique à partir d’un module d’image natif dans un environnement .NET Framework.

Version du produit d’origine : Microsoft .NET Framework 3.5 Service Pack 1
Numéro de base de connaissances d’origine : 2468429

Symptômes

Lorsque vous essayez d’obtenir le descripteur de sécurité d’une classe générique à partir d’un module d’image native (Ngen.exe) dans un environnement Microsoft .NET Framework, vous recevez un message d’erreur d’erreur irrécupérable du moteur d’exécution. Ce problème peut se produire si les conditions suivantes sont remplies :

• L’application inclut un assembly chargé neutre sur le domaine (LoaderOptimization.MultiDomain ou LoaderOptimization.MultiDomainHost).
• L’assembly contient une instanciation d’une classe générique.
• L’assembly a été compilé dans une image native à l’aide de l’outil Générateur d’images natives (Ngen.exe).
• L’application charge l’image native dans un domaine d’application.
• L’application tente d’utiliser la classe générique à partir d’un deuxième domaine d’application sans charger l’image native dans ce domaine d’application.

La cause

Le Common Language Runtime (CLR) peut autoriser l’exécution du code dans l’image native neutre du domaine dans le deuxième domaine d’application, même si l’image native n’a pas encore été chargée dans ce domaine d’application. Si le CLR tente d’obtenir un descripteur de sécurité avant le chargement de l’image native (par exemple, lorsqu’un délégué est créé pour une méthode du type générique instancié), une erreur irrécupérable du moteur d’exécution peut se produire.

Ce problème est difficile à reproduire. Le CLR charge agressivement des assemblys dans des domaines d’application. Par exemple, si un Type objet est passé dans un domaine d’application, le CLR charge l’assembly qui définit le type. Par conséquent, il n’est pas facile pour le deuxième domaine d’application d’obtenir des informations sur la classe générique instanciée sans que le CLR charge l’assembly. Les chemins de code qui contribuent à ce problème se produisent uniquement dans des scénarios complexes.

Contournements

Pour contourner ce problème, utilisez l’une des méthodes suivantes :

• Chargez explicitement l’assembly dans chaque domaine d’application qui l’utilisera. Par exemple, chargez l’assembly en appelant la Assembly.Load méthode.

• Ne chargez pas l’assembly comme neutre dans le domaine.

  Remarque

  Cette solution de contournement peut affecter la taille du jeu de travail de l’application.

• N’utilisez pas l’outil Ngen.exe pour créer une image native pour l’assembly.

  Remarque

  Cette solution de contournement peut affecter les performances de l’application.

• Mettez à niveau l’application vers .NET Framework version 4. Tous les problèmes connus pour contribuer à ce problème ont été résolus dans le .NET Framework 4.