Partager via


Choix du format des fichiers d'entrée .netmodule

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. .netmodules contiennent uniquement des métadonnées.

Vous pouvez transmettre un fichier MSIL .obj à tout autre compilateur Visual Studio via l’option du compilateur /addmodule (mais sachez que le fichier .obj fait partie de l’assembly résultant et doit être fourni avec l’assembly). Par exemple, Visual C# et Visual Basic ont l’option du compilateur /addmodule.

Remarque

Dans la plupart des cas, vous devez passer au fichier .obj de l’éditeur de liens à partir de la compilation qui a créé le module .net. Le passage d’un fichier de module .dll ou .netmodule MSIL à l’éditeur de liens peut entraîner LNK1107.

Les fichiers .obj, ainsi que leurs fichiers .h associés, que vous référencez via #include dans la source, autorisent les applications C++ à consommer les types natifs dans le module, tandis que dans un fichier .netmodule, seuls les types managés peuvent être consommés par une application C++. Si vous tentez de transmettre un fichier .obj à #using, les informations sur les types natifs ne seront pas disponibles ; #include le fichier .obj du fichier .h à la place.

D’autres compilateurs Visual Studio peuvent uniquement utiliser des types managés à partir d’un module.

Utilisez les éléments suivants pour déterminer si vous devez utiliser un fichier .netmodule ou .obj comme entrée de module dans l’éditeur de liens MSVC :

  • Si vous générez avec un compilateur Visual Studio autre que Visual C++, produisez un .netmodule et utilisez .netmodule comme entrée pour l’éditeur de liens.

  • Si vous utilisez le compilateur MSVC pour produire des modules et si le ou les modules seront utilisés pour générer quelque chose d’autre qu’une bibliothèque, utilisez les fichiers .obj générés par le compilateur comme entrée de module pour l’éditeur de liens ; n’utilisez pas le fichier .netmodule comme entrée.

  • Si vos modules seront utilisés pour générer une bibliothèque native (et non gérée), utilisez des fichiers .obj comme entrée de module pour l’éditeur de liens et générez un fichier de bibliothèque .lib.

  • Si vos modules seront utilisés pour générer une bibliothèque managée et si toutes les entrées de module à l’éditeur de liens seront vérifiables (produites avec /clr :safe), utilisez les fichiers .obj comme entrée de module pour l’éditeur de liens et générez un fichier de bibliothèque .dll (assembly) ou .netmodule (module).

  • Si vos modules seront utilisés pour générer une bibliothèque managée et si une ou plusieurs entrées de modules à l’éditeur de liens seront produites avec juste /clr, utilisez des fichiers .obj comme entrée de module pour l’éditeur de liens et générez un fichier .dll (assembly). Si vous souhaitez exposer des types managés à partir de la bibliothèque et si vous souhaitez également que les applications C++ consomment les types natifs dans la bibliothèque, votre bibliothèque se compose des fichiers .obj pour les modules de composant bibliothèques (vous souhaiterez également expédier les fichiers .h pour chaque module, afin qu’elles puissent être référencées avec #include à partir du code source).

Voir aussi

Fichiers .netmodule en tant qu’entrée de l’Éditeur de liens