#using, directive (C++/CLI)
Importe les métadonnées dans un programme compilé avec /clr.
Syntaxe
#usingfichier [as_friend]
Paramètres
file
Un langage microsoft intermédiaire (MSIL) .dll, .exe, .netmoduleou .obj fichier. Par exemple,
#using <MyComponent.dll>
as_friend
Spécifie que tous les types du fichier sont accessibles. Pour plus d’informations, consultez Assemblys friend (C++).
Notes
il peut s’agir d’un fichier MSIL (Microsoft Intermediate Language) que vous importez pour ses données managées et ses constructions managées. Si une DLL contient un manifeste d’assembly, toutes les DLL référencées dans le manifeste sont importées. L’assembly que vous générez répertorie le fichier dans les métadonnées en tant que référence d’assembly.
Peut-être que le fichier ne contient pas d’assembly (fichier est un module), et vous n’avez pas l’intention d’utiliser les informations de type du module dans l’application actuelle (assembly). Vous pouvez indiquer que le module fait partie de l’assembly à l’aide de /ASSEMBLYMODULE. Les types du module sont ensuite accessibles à toute application qui a référencé l'assembly.
Une alternative à utiliser #using est l’option du compilateur /FU .
.exe assemblys passés à doivent être compilés à #using l’aide de l’un des compilateurs .NET Visual Studio (Visual Basic ou Visual C#, par exemple). Toute tentative d'importation des métadonnées à partir d'un assembly .exe compilé avec /clr provoque une exception de chargement du fichier.
Remarque
Un composant référencé avec #using peut être exécuté avec une autre version du fichier importé au moment de la compilation, ce qui entraîne l’exécution d’une application cliente pour donner des résultats inattendus.
Pour que le compilateur reconnaisse un type dans un assembly (et non un module), il doit être forcé de résoudre le type. Vous pouvez la forcer, par exemple, en définissant une instance du type. Il existe d’autres façons de résoudre les noms de types dans un assembly pour le compilateur. Par exemple, si vous héritez d’un type dans un assembly, le nom du type devient connu du compilateur.
Lors de l’importation de métadonnées générées à partir du code source utilisé __declspec(thread), la sémantique de thread n’est pas conservée dans les métadonnées. Par exemple, une variable déclarée avec __declspec(thread), compilée dans un programme créé pour le Common Language Runtime .NET Framework, puis importée via #using, n’aura __declspec(thread) pas de sémantique sur la variable.
Tous les types importés (gérés et natifs) dans un fichier référencé #using par sont disponibles, mais le compilateur traite les types natifs comme des déclarations, et non comme des définitions.
mscorlib.dll est automatiquement référencé lors de la compilation avec /clr.
La variable d’environnement LIBPATH spécifie les répertoires à rechercher lorsque le compilateur résout les noms de fichiers passés à #using.
Le compilateur recherche des références le long du chemin suivant :
Chemin d’accès spécifié dans l’instruction
#using.Répertoire actif.
Répertoire système du .NET Framework.
Répertoires ajoutés avec l’option du
/AIcompilateur.Répertoires sur la variable d'environnement LIBPATH.
Exemples
Vous pouvez créer un assembly qui fait référence à un deuxième assembly qui fait référence à un troisième assembly. Vous devez uniquement référencer explicitement le troisième assembly à partir du premier si vous utilisez explicitement l’un de ses types.
Fichier source using_assembly_A.cpp :
// using_assembly_A.cpp
// compile with: /clr /LD
public ref class A {};
Fichier source using_assembly_B.cpp :
// 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, le compilateur ne signale pas d’erreur sur le référencement de using_assembly_A.dll, car le programme n’utilise aucun des types 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();
}