Elegir el formato de los archivos de entrada .netmodule
Actualización: noviembre 2007
Un archivo MSIL .obj (compilado con /clr) también se puede utilizar como archivo .netmodule. Los archivos .obj contienen metadatos y símbolos nativos. Los archivos .netmodule sólo contienen metadatos.
Se puede pasar un archivo MSIL .obj a cualquier otro compilador de Visual Studio mediante la opción del compilador /addmodule (pero tenga en cuenta que el archivo .obj pasa a formar parte del ensamblado resultante y se debe distribuir con el ensamblado). Por ejemplo, Visual C# y Visual Basic tienen la opción del compilador /addmodule.
.gif "Nota") Nota: |
|---|
En la mayoría de los casos, necesitará pasar al vinculador el archivo .obj desde la compilación que creó el módulo .net. Una excepción a esto es si .netmodule se creó con /clr:pure. Si se pasa un archivo de módulo MSIL .netmodule o .dll al vinculador, se puede producir el error LNK1107. |
Los archivos .obj, junto con sus archivos .h asociados, a los que se hace referencia mediante #include en el código fuente, permiten a las aplicaciones de C++ utilizar los tipos nativos del módulo, mientras que en un archivo .netmodule, una aplicación de C++ sólo puede utilizar los tipos administrados. Si intenta pasar un archivo .obj a #using, la información sobre tipos nativos no estará disponible. En lugar de ello, utilice #include con el archivo .h del archivo .obj.
Otros compiladores de Visual Studio sólo pueden utilizar tipos administrados desde un módulo.
Siga estas pautas para determinar si necesita utilizar un archivo .netmodule o un .obj como entrada de módulo al vinculador de Visual C++:
Si va a utilizar un compilador de Visual Studio distinto de Visual C++, genere un archivo .netmodule y úselo como entrada al vinculador.
Si va a utilizar el compilador de Visual C++ para crear módulos y si éstos se van a usar para generar algo distinto de una biblioteca, use los archivos .obj creados por el compilador como entrada de módulo al vinculador; no utilice el archivo .netmodule como entrada.
Si se van a utilizar los módulos para crear una biblioteca nativa (no una administrada), use archivos .obj como entrada de módulo al vinculador y genere un archivo de biblioteca .lib.
Si se van a utilizar los módulos para crear una biblioteca administrada y si se va a poder comprobar la entrada de todos los módulos al vinculador (creados con /clr:safe), use archivos .obj como entrada de módulo al vinculador y genere un archivo de biblioteca .dll (ensamblado) o .netmodule (módulo).
Si se van a utilizar los módulos para crear una biblioteca administrada y si la entrada de todos los módulos al vinculador se va a crear con /clr:pure o /clr:safe, use archivos .obj como entrada de módulo al vinculador y genere un archivo .dll (ensamblado) o .netmodule (módulo) si sólo desea exponer tipos administrados de la biblioteca. Si desea exponer tipos administrados de la biblioteca y también que las aplicaciones de C++ utilicen los tipos nativos de la biblioteca, ésta consistirá en los archivos .obj para los módulos de componentes de bibliotecas (también querrá distribuir los archivos .h para cada módulo, para que se pueda hacer referencia a ellos con #include desde el código fuente).
Si se van a utilizar los módulos para crear una biblioteca administrada y si la entrada de alguno de los módulos al vinculador se va a crear simplemente con /clr, use archivos .obj como entrada de módulo al vinculador y genere un archivo .dll (ensamblado). Si desea exponer tipos administrados de la biblioteca y también que las aplicaciones de C++ utilicen los tipos nativos de la biblioteca, ésta consistirá en los archivos .obj para los módulos de componentes de bibliotecas (también querrá distribuir los archivos .h para cada módulo, para que se pueda hacer referencia a ellos con #include desde el código fuente).