directive #using (C++)
importe des métadonnées dans un programme compilé avec /clr.
#using file [as_friend]
Paramètres
file
Un code MSIL .dll, .exe..netmodule, ou .obj.Par exemple :#using <MyComponent.dll>
as_friend
Spécifie que tous les types de file sont accessibles.Pour plus d'informations, consultez Assemblys friend (C++).
Notes
file peut être un fichier MSIL (Microsoft intermediate langage) que vous importez pour ses données managées et les éléments sont managés.Si un fichier .DLL contient un manifeste d'assembly, tous les .dll référencés dans le manifeste sont importés et l'assembly que vous générez fichier de listes dans les métadonnées en tant que référence d'assembly.
Si file ne contient pas d'assembly (si file est un module) et si vous n'avez pas l'intention d'utiliser les informations de type du module de l'application actuelle (d'assembly), vous avez la possibilité d'indiquer que le module est partie l'assembly ; utilisation /ASSEMBLYMODULE.Les types dans le module sont ensuite disponibles pour toutes les applications qui a référencé l'assembly.
une alternative pour utiliser #using est l'option du compilateur de /FU .
les assemblys .exe passés à #using doivent être compilées avec /clr:safe ou /clr:pure, ou avec l'une des autres compilateurs Visual Studio (Visual Basic ou Visual c#, par exemple).Si vous essayez d'importer des métadonnées d'un assembly .exe compilé avec /clr entraîne une exception de chargement du fichier.
[!REMARQUE]
un composant qui est référencé avec #using peut être exécuté avec une version différente du fichier importé au moment de la compilation, provoquant une application cliente de donner des résultats inattendus.
Pour qu'un compilateur reconnaisse un type dans un assembly (pas un module), il doit résoudre le type. Pour ce faire, vous pouvez par exemple définir une instance du type.Le compilateur peut résoudre les noms de types d'un assembly de plusieurs autres façons : par exemple, lorsqu'un type est hérité d'un autre type d'un assembly, le nom du type est alors connu du compilateur.
Lors de l'importation de métadonnées a généré de code source que __declspec (thread)utilisé, la sémantique de threads ne sont pas rendu persistant dans les métadonnées.Par exemple, une variable déclarée avec __declspec (thread), compilée dans un programme en cours de génération pour le common langage runtime du .NET Framework, puis importée via #using, ne pourra plus la sémantique de __declspec (thread) sur la variable.
Tous les types importés (managé et natif) dans un fichier référencé par #using sont disponibles, mais les types natifs de compilateur traite comme définitions de déclarations pas.
mscorlib.dll est référencé automatiquement lors de la compilation avec /clr.
La variable d'environnement LIBPATH spécifie les répertoires qui seront présents lorsque le compilateur essaie de résoudre les noms de fichiers passés à #using.
Le compilateur recherche des références selon le chemin suivant :
un chemin d'accès spécifié dans l'instruction d' #using .
Le répertoire actif.
Le répertoire système.NET Framework.
répertoires ajoutés avec l'option du compilateur de /AI .
Répertoires situés dans la variable d'environnement LIBPATH.
Exemple
Si vous générez un assembly (c) et référencez un assembly (b) que lui-même référence un autre assembly (un), vous devez pas explicitement l'assembly de référence A à moins d'utiliser explicitement un d'un saisisse C.
// using_assembly_A.cpp
// compile with: /clr /LD
public ref class A {};
// using_assembly_B.cpp
// compile with: /clr /LD
#using "using_assembly_A.dll"
public ref class B {
public:
void Test(A a) {}
void Test() {}
};
Dans l'exemple suivant, aucune erreur du compilateur pour ne pas référencer using_assembly_A.dll car le programme n'utilise pas les types différents de définis dans using_assembly_A.cpp.
// using_assembly_C.cpp
// compile with: /clr
#using "using_assembly_B.dll"
int main() {
B b;
b.Test();
}