Fichiers .netmodule en tant qu'entrée de l'Éditeur de liens
Mise à jour : novembre 2007
link.exe accepte désormais les fichiers .obj et .netmodule MSIL comme entrées. Le fichier de sortie produit par l'éditeur de liens sera un assembly ou un fichier .netmodule indépendant au moment de l'exécution de tout fichier .obj ou .netmodule entrés dans l'éditeur de liens.
Les fichiers .netmodule sont créés par le compilateur Visual C++ avec /LN (Créer le module MSIL) ou par l'éditeur de liens avec /NOASSEMBLY (Créer un module MSIL). Les fichiers .obj sont toujours créés dans une compilation Visual C++. Pour d'autres compilateurs Visual Studio, utilisez l'option du compilateur /target:module.
Dans la plupart des cas, vous devez passer à l'éditeur de liens le fichier .obj de la compilation Visual C++ qui a créé le fichier .netmodule, à moins que le fichier .netmodule ait été créé avec /clr (Compilation pour le Common Language Runtime). Les fichiers .netmodule MSIL utilisés comme entrées dans l'éditeur de liens doivent être constitués de code MSIL pur pouvant être produit par le compilateur Visual C++ à l'aide de /clr:safe. D'autres compilateurs Visual Studio produisent des modules MSIL purs par défaut.
Pour plus d'informations sur l'appel de l'éditeur de liens à partir de la ligne de commande, consultez Syntaxe de la ligne de commande de l'Éditeur de liens et Définition du chemin d'accès et des variables d'environnement pour la génération à partir de la ligne de commande.
Le passage à l'éditeur de liens d'un fichier .netmodule ou d'un fichier .dll qui a été compilé par le compilateur Visual C++ avec /clr ou avec /clr:pure peut entraîner une erreur de l'éditeur de liens. Pour plus d'informations, consultez Choix du format des fichiers d'entrée .netmodule.
L'éditeur de liens accepte les fichiers .obj natifs ainsi que les fichiers .obj MSIL compilés avec /clr, /clr:pureou /clr:safe. Lors du passage de fichiers .obj mixtes dans la même version, la vérifiabilité du fichier de sortie résultant équivaut par défaut au niveau le plus bas de vérifiabilité des modules d'entrée. Par exemple, si vous passez un fichier .obj sécurisé et pur à l'éditeur de liens, le fichier de sortie sera pur. /CLRIMAGETYPE (Spécifier le type d'une image CLR) permet de spécifier un niveau inférieur de vérifiabilité, si c'est ce dont vous avez besoin.
Si vous possédez actuellement une application composée de plusieurs assemblys et si vous souhaitez qu'elle soit contenue dans un assembly, vous devez recompiler les assemblys, puis lier les fichiers .obj ou .netmodule pour produire un assembly unique.
Vous devez spécifier un point d'entrée à l'aide de /ENTRY (Symbole de point d'entrée) lors de la création d'une image exécutable.
Lors de la liaison avec un fichier .obj ou .netmodule MSIL, utilisez /LTCG (Génération de code durant l'édition de liens), sinon lorsque l'éditeur de liens rencontre ce fichier, il redémarre la liaison avec /LTCG.
Les fichiers .obj ou .netmodule MSIL peuvent également être passés à cl.exe.
Les fichiers d'entrée .obj ou .netmodule MSIL ne peuvent pas posséder de ressources incorporées. Une ressource est incorporée dans un fichier de sortie (module ou assembly) avec l'option de l'éditeur de liens /ASSEMBLYRESOURCE (Incorporer une ressource managée) ou avec l'option du compilateur /resource dans d'autres compilateurs Visual Studio.
Lors de l'exécution de la liaison MSIL, si vous ne spécifiez pas également /LTCG (Génération de code durant l'édition de liens), un message d'information s'affiche pour signaler que la liaison redémarre. Ce message peut être ignoré, mais pour améliorer les performances de l'éditeur de liens avec la liaison MSIL, spécifiez explicitement /LTCG.
Exemple
Dans le code C++, le bloc catch d'une clause try correspondante est appelé pour une exception autre que System. Toutefois, le CLR encapsule par défaut les exceptions autres que System avec RuntimeWrappedException. Lorsqu'un assembly est créé à partir de modules Visual C++ et autres et que vous souhaitez appeler un bloc catch dans le code C++ à partir de sa clause try correspondante lorsque le bloc try lève une exception autre que System, vous devez ajouter
l'attribut [assembly:System::Runtime::CompilerServices::RuntimeCompatibility (WrapNonExceptionThrows=false)] au code source pour les modules autres que C++.
// MSIL_linking.cpp
// compile with: /c /clr
value struct V {};
ref struct MCPP {
static void Test() {
try {
throw (gcnew V);
}
catch (V ^) {
System::Console::WriteLine("caught non System exception in C++ source code file");
}
}
};
/*
int main() {
MCPP::Test();
}
*/
En modifiant la valeur Boolean de l'attribut WrapNonExceptionThrows, le code Visual C++ ne peut pas intercepter une exception autre que System.
// MSIL_linking_2.cs
// compile with: /target:module /addmodule:MSIL_linking.obj
// post-build command: link /LTCG MSIL_linking.obj MSIL_linking_2.netmodule /entry:MLinkTest.Main /out:MSIL_linking_2.exe /subsystem:console
using System.Runtime.CompilerServices;
// enable non System exceptions
[assembly:RuntimeCompatibility(WrapNonExceptionThrows=false)]
class MLinkTest {
public static void Main() {
try {
MCPP.Test();
}
catch (RuntimeWrappedException) {
System.Console.WriteLine("caught a wrapped exception in C#");
}
}
}
caught non System exception in C++ source code file