directiva #using (C++)
importa metadatos en un programa compilado con /clr.
#using file [as_friend]
Parámetros
file
MSIL .dll, .exe.netmodule, o .obj.Por ejemplo,#using <MyComponent.dll>
as_friend
Especifica que todos los tipos de file son accesibles.Para obtener más información, vea Ensamblados de confianza (C++).
Comentarios
file puede ser un archivo de lenguaje intermedio de Microsoft (MSIL) que importa para sus datos administrados y construcciones administradas.Si un archivo .dll contiene un manifiesto del ensamblado, después todos los archivos .dll hace referencia en el manifiesto se importan y el ensamblado que está compilando archivo de metadatos como referencia de ensamblado.
Si file no contiene un ensamblado (si file es un módulo) y si no piensa utilizar la información de tipo de módulo de la aplicación actual (del ensamblado), tiene la opción solo para indicar que el módulo es parte el ensamblado; uso /ASSEMBLYMODULE.Los tipos del módulo a estará disponible para cualquier aplicación que hiciera referencia al ensamblado.
Una alternativa a utilizar #using es la opción del compilador /FU .
los ensamblados .exe pasados a #using deben compilarse con /clr:safe o /clr:pure, o con cualquiera de los otros compiladores de Visual Studio (Visual Basic o Visual c#, por ejemplo).Al intentar importar metadatos de un ensamblado .exe compilado con /clr producirá una excepción de carga del archivo.
[!NOTA]
Un componente que se hace referencia con #using puede ejecutarse con una versión diferente del archivo importado en tiempo de compilación, produciendo una aplicación cliente para proporcionar resultados inesperados.
Para que el compilador reconozca un tipo en un ensamblado (no en un módulo), debe obligársele a que resuelva el tipo, lo que se puede conseguir, por ejemplo, definiendo una instancia del tipo.Existen otras formas de que el compilador resuelva nombres de tipos en un ensamblado; por ejemplo, si se hereda de un tipo de un ensamblado, el compilador reconocerá el nombre del tipo.
Al importar metadatos compiló a partir del código fuente que utilizó __declspec (subproceso), la semántica de subproceso no se conservan en metadatos.Por ejemplo, una variable declarada con __declspec (subproceso), compilado en un programa compilado para Common Language Runtime de.NET Framework, y después se importe mediante #using, carecerá semántica de __declspec (subproceso) en la variable.
Todos los tipos importados (administrado y nativo) en un archivo de referencia por #using están disponibles, pero el compilador trata tipos nativos como definiciones de declaraciones no.
mscorlib.dll automáticamente se hace referencia al compilar con /clr.
La variable de entorno LIBPATH especifica los directorios que se busca al compilador intenta resolver los nombres de archivo pasados a #using.
El compilador buscará las referencias a lo largo de la ruta de acceso siguiente:
Una ruta de acceso especificada en la instrucción de #using .
El directorio actual.
El directorio system de .NET Framework.
Directorios agregados con la opción del compilador /AI .
Directorios de variable de entorno LIBPATH.
Ejemplo
Si compila un ensamblado (c) y hace referencia a un ensamblado (b) que sí mismo hace referencia a otro ensamblado (a), no tendrá que hacer referencia explícitamente al ensamblado A menos que explícitamente utilice uno de los tipos de C de a.
// using_assembly_A.cpp
// compile with: /clr /LD
public ref class A {};
// using_assembly_B.cpp
// compile with: /clr /LD
#using "using_assembly_A.dll"
public ref class B {
public:
void Test(A a) {}
void Test() {}
};
En el ejemplo siguiente, no hay ningún error del compilador para no hacer referencia using_assembly_A.dll porque el programa no utiliza los cualquiera de los tipos definidos en using_assembly_A.cpp.
// using_assembly_C.cpp
// compile with: /clr
#using "using_assembly_B.dll"
int main() {
B b;
b.Test();
}