Choix du format des fichiers d'entrée .netmodule
Mise à jour : novembre 2007
Un fichier .obj MSIL (compilé avec /clr) peut également être utilisé comme fichier .netmodule. Les fichiers .obj contiennent des métadonnées et des symboles natifs. Les fichiers .netmodule contiennent uniquement des métadonnées.
Vous pouvez passer un fichier .obj MSIL à tout autre compilateur Visual Studio via l'option du compilateur /addmodule (mais n'oubliez pas que le fichier .obj devient partie intégrante de l'assembly résultant et doit être expédié avec l'assembly). Par exemple, Visual C# et Visual Basic proposent l'option du compilateur /addmodule.
.gif "Remarque") Remarque : |
|---|
Dans la plupart des cas, vous devrez passer à l'éditeur de liens le fichier .obj de la compilation qui a créé le module .net, sauf si le fichier .netmodule a été créé avec /clr:pure. Le passage d'un fichier module MSIL .dll ou .netmodule à l'éditeur de liens peut entraîner l'erreur LNK1107. |
Les fichiers .obj, avec leurs fichiers .h associés que vous pouvez référencer à l'aide de #include dans la source, permettent aux applications C++ d'utiliser les types natifs dans le module, alors que dans un fichier .netmodule, seuls les types managés peuvent être utilisés par une application C++. Si vous essayez de passer un fichier .obj à #using, les informations relatives aux types natifs ne sont pas disponibles ; utilisez plutôt #include pour inclure le fichier .h du fichier .obj.
D'autres compilateurs Visual Studio ne peuvent utiliser que des types managés provenant d'un module.
Procédez des manières suivantes pour déterminer si vous devez utiliser un fichier .netmodule ou un fichier .obj comme entrée de module dans l'éditeur de liens Visual C++ :
Si vous procédez à la génération avec un compilateur Visual Studio autre que Visual C++, produisez un fichier .netmodule et utilisez-le comme entrée dans l'éditeur de liens.
Si vous utilisez le compilateur Visual C++ pour produire des modules et si le ou les modules doivent être utilisés pour générer autre chose qu'une bibliothèque, utilisez les fichiers .obj produits par le compilateur comme entrée de module dans l'éditeur de liens ; n'utilisez pas le fichier .netmodule comme entrée.
Si vos modules sont utilisés pour générer une bibliothèque native (et non managée), utilisez les fichiers .obj comme entrée de module dans l'éditeur de liens et générez un fichier bibliothèque .lib.
Si vos modules sont utilisés pour générer une bibliothèque managée, et si toutes les entrées de module dans l'éditeur de liens sont vérifiables (produites avec /clr:safe), utilisez les fichiers .obj comme entrée de module dans l'éditeur de liens et générez un fichier bibliothèque .dll (assembly) ou .netmodule (module).
Si vos modules sont utilisés pour générer une bibliothèque managée, et si toutes les entrées de module dans l'éditeur de liens sont produites avec /clr:pure ou /clr:safe, utilisez les fichiers .obj comme entrée de module dans l'éditeur de liens et générez un fichier .dll (assembly) ou .netmodule (module) si vous souhaitez uniquement exposer les types managés de la bibliothèque. Si vous souhaitez exposer les types managés de la bibliothèque et si vous désirez également que les applications C++ utilisent les types natifs dans la bibliothèque, votre bibliothèque se composera des fichiers .obj pour les modules de composants de bibliothèques (vous pouvez également expédier les fichiers .h de chaque module afin qu'ils puissent être référencés avec #include dans le code source).
Si vos modules sont utilisés pour générer une bibliothèque managée, et si un ou plusieurs modules entrés dans l'éditeur de liens sont produits avec /clr uniquement, utilisez les fichiers .obj comme entrée de module dans l'éditeur de liens et générez un fichier .dll (assembly). Si vous souhaitez exposer les types managés de la bibliothèque et si vous désirez également que les applications C++ utilisent les types natifs dans la bibliothèque, votre bibliothèque se composera des fichiers .obj pour les modules de composants de bibliothèques (vous pouvez également expédier les fichiers .h de chaque module afin qu'ils puissent être référencés avec #include dans le code source).