MISE À JOUR POUR .NET 4.0 ET PLUS DE CADRES RÉCENTS
C'est une vieille question posée à l'époque de .Net 2.0, lorsque la prise en charge des DLL en mode mixte présentait de graves problèmes d'initialisation, sujets à des blocages aléatoires. Depuis .Net 4.0, l'initialisation des DLL en mode mixte a changé. Maintenant, il y a deux étapes distinctes d'initialisation:
- Initialisation native, appelée au point d'entrée de la DLL, qui inclut la configuration d'exécution native C ++ et l'exécution de votre méthode DllMain.
- Initialisation gérée, exécutée automatiquement par le chargeur système.
Puisque l'étape n ° 2 est effectuée en dehors du verrou du chargeur, il n'y a pas de blocage. Les détails sont décrits dans Initialisation des assemblys mixtes .
Pour vous assurer que votre assembly en mode mixte peut être chargé à partir d'un exécutable natif, la seule chose que vous devez vérifier est que la méthode DllMain est déclarée en tant que code natif. #pragma unmanagedpourrait aider ici:
#pragma unmanaged
BOOL APIENTRY DllMain(HMODULE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved
)
{
... // your implementation here
}
Il est également important que tout code que DllMain pourrait appeler directement ou indirectement soit également non géré. Il est logique de limiter le type de fonctionnalité utilisée par DllMain afin de suivre tout le code accessible à partir de DllMain et de vous assurer qu'il est entièrement compilé avec #pragma unmanaged.
Le compilateur aide un peu en vous avertissant C4747 s'il détecte que DllMain n'est pas déclaré comme non géré:
1> Generating Code...
1>E:\src\mixedmodedll\dllmain.cpp : warning C4747: Calling managed 'DllMain': Managed code may not be run under loader lock, including the DLL entrypoint and calls reached from the DLL entrypoint
Cependant, le compilateur ne générera aucun avertissement si DllMain appelle indirectement une autre fonction gérée, vous devez donc vous assurer que cela ne se produit jamais, sinon votre application pourrait se bloquer de manière aléatoire.
