Choix du format des fichiers d'entrée .netmodule
Un fichier .obj MSIL (compilé avec /clr) peut également être utilisé commefichier .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.
[!REMARQUE]
Dans la plupart des cas, vous devrez passer à l'éditeur de liens le fichier .obj de la compilation qui a créé lemodule .net,sauf si le fichier.netmodule a été créé avec /clr:pure.Le passage d'un fichier de module MSIL .dll ou.netmodule à l'éditeur de liens peut générer l'erreur LNK1107.
Les fichiers .obj, avec les fichiers .h associés, que vous pouvez référencer via #include dans la source, permettent aux applications C++ d'utiliser les types natifs dans le module, alors que dans unfichier .netmodule, seuls les types managés peuvent être employé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 comme suit pour déterminer si vous devez utiliser unfichier .netmodule ou un fichier .obj comme entrée de module de l'éditeur de liens Visual C++ :
Si vous procédez à la génération avec un compilateur Visual Studio autre que Visual C++, produisez unfichier .netmodule et utilisez-lecomme entrée de l'éditeur de liens.
Si vous utilisez le compilateur Visual C++ pour produire des modules et si les modules doivent être utilisés pour générer un élément autre qu'une bibliothèque, employez les fichiers .obj produits par le compilateur comme entrée de module de l'éditeur de liens ; n'utilisez pas lefichier .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 de l'éditeur de liens sont vérifiables (produites avec /clr:safe), utilisez les fichiers .obj comme entrée de module de 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 de l'éditeur de liens sont produites avec /clr:pure ou /clr:safe, utilisez les fichiers .obj comme entrée de module de 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).