Exportar (0) Imprimir
Expandir todo
Este tema aún no ha recibido ninguna valoración - Valorar este tema

.Archivos netmodule como entrada del vinculador

Actualización: noviembre 2007

link.exe ahora acepta archivos MSIL .obj y .netmodule como entrada. El archivo de resultados generado por el vinculador será un ensamblado o .netmodule sin dependencia en tiempo de ejecución de ninguno de los archivos .obj o .netmodule que se utilizaron como entrada al vinculador.

El compilador de Visual C++ crea los archivos .netmodule con /LN (Crear un módulo MSIL) o mediante el vinculador con /NOASSEMBLY (Crear un módulo MSIL). Los archivos .obj siempre se crean en una compilación de Visual C++. Para otros compiladores de Visual Studio, utilice la opción del compilador /target:module.

En la mayoría de los casos, necesitará pasar al vinculador el archivo .obj desde la compilación de Visual C++ que creó el .netmodule, a no ser que el .netmodule se haya creado con /clr (Compilación de Common Language Runtime). Los archivos MSIL .netmodule utilizados como entrada al vinculador deben ser MSIL puros, que se pueden generar mediante el compilador de Visual C++ utilizando /clr:safe. Otros compiladores de Visual Studio generan de manera predeterminada módulos MSIL puros.

Para obtener información sobre cómo invocar al vinculador desde la línea de comandos, vea Sintaxis de la línea de comandos del vinculador y Establecer la ruta de acceso y las variables de entorno para generar desde la línea de comandos.

Si se pasa un archivo .netmodule o .dll al vinculador que se compiló mediante el compilador de Visual C++ con /clr o /clr:pure, puede generarse un error. Para obtener más información, vea Elegir el formato de los archivos de entrada .netmodule.

El vinculador acepta los archivos .obj nativos así como archivos .obj MSIL compilados con /clr, /clr:pure o /clr:safe. Cuando se pasan archivos .obj mixtos en la misma versión de compilación, la verificabilidad del archivo de resultados será, de forma predeterminada, igual al nivel inferior de verificabilidad de los módulos de entrada. Por ejemplo, si pasa un .obj seguro y uno puro al vinculador, el archivo de resultados será puro. /CLRIMAGETYPE (Especificar tipo de imagen CLR) le permite especificar un nivel inferior de verificabilidad, si es necesario.

Si ya tiene una aplicación que está compuesta por dos o más ensamblados y desea que la aplicación esté contenida en un ensamblado, debe volver a compilar los ensamblados y luego vincular los archivos .obj y .netmodule para producir un único ensamblado.

Debe especificar un punto de entrada mediante /ENTRY (Símbolo de punto de entrada) al crear una imagen ejecutable.

Cuando establezca un vínculo con un archivo MSIL .obj o .netmodule, use /LTCG (Generación de código en tiempo de enlace). Si no lo hace, cuando el vinculador encuentre el MSIL .obj o .netmodule, reiniciará el vínculo con /LTCG.

Los archivos MSIL .obj o .netmodule también se pueden pasar a cl.exe.

Los archivos MSIL .obj o .netmodule de entrada no pueden tener recursos incrustados. Un recurso se incrusta en un archivo de resultados (módulo o ensamblado) con la opción del vinculador /ASSEMBLYRESOURCE (Incrustar un recurso administrado) o con la opción del compilador /resource en otros compiladores de Visual Studio.

Cuando realice una vinculación de MSIL, y si tampoco especifica /LTCG (Generación de código en tiempo de enlace), verá un mensaje informativo que indica que el vínculo se está reiniciando. Este mensaje se puede omitir pero, para mejorar el rendimiento del vinculador con vinculación con MSIL, especifique explícitamente /LTCG.

En código C++, se llamará al bloque Catch del Try correspondiente para una excepción que no sea del sistema. Sin embargo, de forma predeterminada, CLR contiene excepciones que no son del sistema con RuntimeWrappedException. Si se crea un ensamblado desde módulos de Visual C++ y que no sean de Visual C++, y desea que se llame un bloque Catch en código C++ desde su correspondiente cláusula Try cuando el bloque Try produce una excepción que no es del sistema, debe agregar el atributo

[assembly:System::Runtime::CompilerServices::RuntimeCompatibility (WrapNonExceptionThrows=false)] al código fuente para los módulos que no sean de 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();
}
*/

Al cambiar el valor booleano del atributo WrapNonExceptionThrows, modifica la capacidad del código de Visual C++ para detectar una excepción que no sea del sistema.

// 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
¿Te ha resultado útil?
(Caracteres restantes: 1500)
Gracias por sus comentarios

Adiciones de comunidad

AGREGAR
Mostrar:
© 2014 Microsoft. Reservados todos los derechos.