Résoudre les chargements d’assembly
.NET fournit l’événement AppDomain.AssemblyResolve pour les applications qui nécessitent un meilleur contrôle du chargement d’assembly. En gérant cet événement, votre application peut charger un assembly dans le contexte de chargement à l’extérieur des chemins de détection normaux, sélectionner la version d’assembly à charger parmi plusieurs, émettre un assembly dynamique et le retourner, etc. Cette rubrique fournit des instructions sur la gestion de l’événement AssemblyResolve.
Notes
Pour résoudre les chargements d’assemblys dans le contexte ReflectionOnly, utilisez l’événement AppDomain.ReflectionOnlyAssemblyResolve à la place.
Fonctionnement de l’événement AssemblyResolve
Quand vous inscrivez un gestionnaire pour l’événement AssemblyResolve, le gestionnaire est appelé chaque fois que le runtime ne peut pas établir de liaison à un assembly par nom. Par exemple, l’appel des méthodes suivantes à partir du code utilisateur peut provoquer le déclenchement de l’événement AssemblyResolve :
surcharge de méthode AppDomain.Load ou Assembly.Load dont le premier argument est une chaîne qui représente le nom complet de l’assembly à charger (autrement dit, la chaîne retournée par la propriété Assembly.FullName) ;
surcharge de méthode AppDomain.Load ou Assembly.Load dont le premier argument est un objet AssemblyName qui identifie l’assembly à charger ;
surcharge de méthode Assembly.LoadWithPartialName ;
surcharge de méthode AppDomain.CreateInstance ou AppDomain.CreateInstanceAndUnwrap qui instancie un objet dans un autre domaine d’application.
Rôle du gestionnaire d’événements
Le gestionnaire de l’événement AssemblyResolve reçoit le nom complet de l’assembly à charger dans la propriété ResolveEventArgs.Name. Si le gestionnaire ne reconnaît pas le nom de l’assembly, il retourne null
(C#), Nothing
(Visual Basic) ou nullptr
(Visual C++).
Si le gestionnaire reconnaît le nom de l’assembly, il peut charger et retourner un assembly qui satisfait la requête. La liste suivante décrit des exemples de scénarios.
Si le gestionnaire connaît l’emplacement d’une version de l’assembly, il peut charger l’assembly à l’aide de la méthode Assembly.LoadFrom ou Assembly.LoadFile, et retourner l’assembly chargé si l’opération réussit.
Si le gestionnaire a accès à une base de données d’assemblys stockés sous la forme de tableaux d’octets, il peut charger un tableau d’octets à l’aide de l’une des surcharges de méthode Assembly.Load qui acceptent un tableau d’octets.
Le gestionnaire peut générer un assembly dynamique et le retourner.
Notes
Le gestionnaire doit charger l’assembly dans le contexte de chargement source, dans le contexte de chargement ou sans contexte. Si le gestionnaire charge l’assembly dans le contexte de réflexion uniquement à l’aide de la méthode Assembly.ReflectionOnlyLoad ou Assembly.ReflectionOnlyLoadFrom, la tentative de chargement qui a déclenché l’événement AssemblyResolve échoue.
Il appartient au gestionnaire d’événements de retourner un assembly approprié. Le gestionnaire peut analyser le nom complet de l’assembly demandé en passant la valeur de propriété ResolveEventArgs.Name au constructeur AssemblyName(String). À compter de .NET Framework 4, le gestionnaire peut utiliser la propriété ResolveEventArgs.RequestingAssembly pour déterminer si la requête actuelle est une dépendance d’un autre assembly. Ces informations permettent d’identifier un assembly qui satisfait la dépendance.
Le gestionnaire d’événements peut retourner une version de l’assembly différente de celle qui a été demandée.
Dans la plupart des cas, l’assembly qui est retourné par le gestionnaire apparaît dans le contexte de chargement, indépendamment du contexte dans lequel le gestionnaire le charge. Par exemple, si le gestionnaire utilise la méthode Assembly.LoadFrom pour charger un assembly dans le contexte LoadFrom, l’assembly apparaît dans le contexte de chargement quand le gestionnaire le retourne. Toutefois, dans le cas suivant, l’assembly apparaît sans contexte quand le gestionnaire le retourne :
le gestionnaire charge un assembly sans contexte ;
la propriété ResolveEventArgs.RequestingAssembly n’a pas la valeur Null ;
l’assembly demandeur (c’est-à-dire, l’assembly retourné par la propriété ResolveEventArgs.RequestingAssembly) a été chargé sans contexte.
Pour plus d’informations sur les contextes, consultez la surcharge de méthode Assembly.LoadFrom(String).
Vous pouvez charger plusieurs versions du même assembly dans le même domaine d’application. Cette pratique n’est pas recommandée, car elle peut entraîner des problèmes d’assignation de type. Consultez Bonnes pratiques pour le chargement d’assemblys.
Ce que le gestionnaire d’événements ne doit pas faire
La règle principale pour gérer l’événement AssemblyResolve est que vous ne devez pas essayer de retourner un assembly que vous ne reconnaissez pas. Quand vous écrivez le gestionnaire, vous devez avoir connaissance des assemblys qui peuvent provoquer le déclenchement de l’événement. Votre gestionnaire doit retourner Null pour d’autres assemblys.
Important
À compter de .NET Framework 4, l’événement AssemblyResolve est déclenché pour les assemblys satellites. Ce changement affecte un gestionnaire d’événements qui a été écrit pour une version antérieure du .NET Framework, si le gestionnaire tente de résoudre toutes les requêtes de chargement d’assembly. Les gestionnaires d’événements qui ignorent les assemblys non reconnus ne sont pas affectés par ce changement : ils retournent null
et les mécanismes de secours normaux sont suivis.
Durant le chargement d’un assembly, le gestionnaire d’événements ne doit pas utiliser les surcharges de méthode AppDomain.Load et Assembly.Load qui peuvent provoquer le déclenchement de l’événement AssemblyResolve de manière récursive, car cela peut provoquer un dépassement de capacité de la pile. (Voir la liste fournie précédemment dans la rubrique) Cela se produit même si vous fournissez la gestion des exceptions pour la requête de chargement, car aucune exception n’est levée tant que tous les gestionnaires d’événements ne sont pas retournés. Le code suivant provoque donc un dépassement de capacité de la pile si MyAssembly
est introuvable :
using System;
using System.Reflection;
class BadExample
{
static void Main()
{
AppDomain ad = AppDomain.CreateDomain("Test");
ad.AssemblyResolve += MyHandler;
try
{
object obj = ad.CreateInstanceAndUnwrap(
"MyAssembly, version=1.2.3.4, culture=neutral, publicKeyToken=null",
"MyType");
}
catch (Exception ex)
{
Console.WriteLine(ex.Message);
}
}
static Assembly MyHandler(object source, ResolveEventArgs e)
{
Console.WriteLine("Resolving {0}", e.Name);
// DO NOT DO THIS: This causes a StackOverflowException
return Assembly.Load(e.Name);
}
}
/* This example produces output similar to the following:
Resolving MyAssembly, Version=1.2.3.4, Culture=neutral, PublicKeyToken=null
Resolving MyAssembly, Version=1.2.3.4, Culture=neutral, PublicKeyToken=null
...
Resolving MyAssembly, Version=1.2.3.4, Culture=neutral, PublicKeyToken=null
Resolving MyAssembly, Version=1.2.3.4, Culture=neutral, PublicKeyToken=null
Process is terminated due to StackOverflowException.
*/
Imports System.Reflection
Class BadExample
Shared Sub Main()
Dim ad As AppDomain = AppDomain.CreateDomain("Test")
AddHandler ad.AssemblyResolve, AddressOf MyHandler
Try
Dim obj As object = ad.CreateInstanceAndUnwrap(
"MyAssembly, version=1.2.3.4, culture=neutral, publicKeyToken=null",
"MyType")
Catch ex As Exception
Console.WriteLine(ex.Message)
End Try
End Sub
Shared Function MyHandler(ByVal source As Object, _
ByVal e As ResolveEventArgs) As Assembly
Console.WriteLine("Resolving {0}", e.Name)
// DO NOT DO THIS: This causes a StackOverflowException
Return Assembly.Load(e.Name)
End Function
End Class
' This example produces output similar to the following:
'
'Resolving MyAssembly, Version=1.2.3.4, Culture=neutral, PublicKeyToken=null
'Resolving MyAssembly, Version=1.2.3.4, Culture=neutral, PublicKeyToken=null
'...
'Resolving MyAssembly, Version=1.2.3.4, Culture=neutral, PublicKeyToken=null
'Resolving MyAssembly, Version=1.2.3.4, Culture=neutral, PublicKeyToken=null
'
'Process is terminated due to StackOverflowException.
using namespace System;
using namespace System::Reflection;
ref class Example
{
internal:
static Assembly^ MyHandler(Object^ source, ResolveEventArgs^ e)
{
Console::WriteLine("Resolving {0}", e->Name);
// DO NOT DO THIS: This causes a StackOverflowException
return Assembly::Load(e->Name);
}
};
void main()
{
AppDomain^ ad = AppDomain::CreateDomain("Test");
ad->AssemblyResolve += gcnew ResolveEventHandler(&Example::MyHandler);
try
{
Object^ obj = ad->CreateInstanceAndUnwrap(
"MyAssembly, version=1.2.3.4, culture=neutral, publicKeyToken=null",
"MyType");
}
catch (Exception^ ex)
{
Console::WriteLine(ex->Message);
}
}
/* This example produces output similar to the following:
Resolving MyAssembly, Version=1.2.3.4, Culture=neutral, PublicKeyToken=null
Resolving MyAssembly, Version=1.2.3.4, Culture=neutral, PublicKeyToken=null
...
Resolving MyAssembly, Version=1.2.3.4, Culture=neutral, PublicKeyToken=null
Resolving MyAssembly, Version=1.2.3.4, Culture=neutral, PublicKeyToken=null
Process is terminated due to StackOverflowException.
*/
La bonne façon de gérer AssemblyResolve
Lors de la résolution d’assemblys à partir du gestionnaire d’événements AssemblyResolve, une StackOverflowException est levée si le gestionnaire utilise les appels de méthode Assembly.Load ou AppDomain.Load. Au lieu de cela, utilisez les méthodes LoadFile ou LoadFrom, car elles ne déclenchent pas l’événement AssemblyResolve
.
Imaginez que MyAssembly.dll
se trouve près de l’assembly en cours d’exécution, dans un emplacement connu, il peut être résolu à l’aide de Assembly.LoadFile
en disposant du chemin d’accès à l’assembly.
using System;
using System.IO;
using System.Reflection;
class CorrectExample
{
static void Main()
{
AppDomain ad = AppDomain.CreateDomain("Test");
ad.AssemblyResolve += MyHandler;
try
{
object obj = ad.CreateInstanceAndUnwrap(
"MyAssembly, version=1.2.3.4, culture=neutral, publicKeyToken=null",
"MyType");
}
catch (Exception ex)
{
Console.WriteLine(ex.Message);
}
}
static Assembly MyHandler(object source, ResolveEventArgs e)
{
Console.WriteLine("Resolving {0}", e.Name);
var path = Path.GetFullPath("../../MyAssembly.dll");
return Assembly.LoadFile(path);
}
}
Imports System.IO
Imports System.Reflection
Class CorrectExample
Shared Sub Main()
Dim ad As AppDomain = AppDomain.CreateDomain("Test")
AddHandler ad.AssemblyResolve, AddressOf MyHandler
Try
Dim obj As Object = ad.CreateInstanceAndUnwrap(
"MyAssembly, version=1.2.3.4, culture=neutral, publicKeyToken=null",
"MyType")
Catch ex As Exception
Console.WriteLine(ex.Message)
End Try
End Sub
Shared Function MyHandler(ByVal source As Object,
ByVal e As ResolveEventArgs) As Assembly
Console.WriteLine("Resolving {0}", e.Name)
Dim fullPath = Path.GetFullPath("../../MyAssembly.dll")
Return Assembly.LoadFile(fullPath)
End Function
End Class
using namespace System;
using namespace System::IO;
using namespace System::Reflection;
ref class Example
{
internal:
static Assembly^ MyHandler(Object^ source, ResolveEventArgs^ e)
{
Console::WriteLine("Resolving {0}", e->Name);
String^ fullPath = Path::GetFullPath("../../MyAssembly.dll");
return Assembly::LoadFile(fullPath);
}
};
void main()
{
AppDomain^ ad = AppDomain::CreateDomain("Test");
ad->AssemblyResolve += gcnew ResolveEventHandler(&Example::MyHandler);
try
{
Object^ obj = ad->CreateInstanceAndUnwrap(
"MyAssembly, version=1.2.3.4, culture=neutral, publicKeyToken=null",
"MyType");
}
catch (Exception^ ex)
{
Console::WriteLine(ex->Message);
}
}