www org mapwindows mapwindow español .net vb.net visual-studio-2010 assemblies reference

.net - org - Visual Basic, ¿por qué no puedo importar "System.Drawing" cuando mi única referencia es "Sistema"?



mapwindows 5 (4)

En Visual Studio 10 - Visual Basic, ¿por qué no puedo importar "System.Drawing" cuando mi única referencia es "Sistema"? Puedo importar "System.Runtime.InteropServices".

Para reproducir mi problema:
1. Cree un nuevo proyecto en Visual Studio 10 con la plantilla de biblioteca de clases de Visual Basic.
2. Agregue "Imports System.Drawing" e "Imports System.Runtime.InteropServices" al comienzo.
3. Elimine todas las referencias excepto "Sistema" en el panel Referencias de las propiedades del proyecto.

Resultado: Visual Studio no puede encontrar "System.Drawing" pero puede encontrar "System.Runtime.InteropServices". "System.Drawing" está completamente calificado para que el sistema pueda encontrarlo dentro del "Sistema" al que se hace referencia.

Pensamientos: Parece que "Sistema" y "Sistema.Dibujo" son espacios de nombres distintos (¿o contenedores?) Entonces ¿por qué no la calificación "." ¿trabajo? Hace "." representar algo más?

"Sistema" también está en "mscorlib" pero ¿es ese el espacio de nombres que se usa o es otro?

"Microsoft.VisualBasic" también aparece en los espacios de nombres importados, pero no hay una referencia al mismo. ¿Cómo se encontró? ¿De dónde viene la lista "Espacios de nombres importados"?

Un enlace a cualquier información relacionada de la biblioteca de MSDN definitivamente sería útil. Lo he estado buscando durante un tiempo pero no puedo entender por qué "System.Drawing" no se importa.


El espacio de nombres System.Drawing "vive" en otra dll a la que no se hace referencia inicialmente en el proyecto de plantilla para una biblioteca de clases. Deberá agregar una referencia a System.Drawing (haga clic derecho en el proyecto -> add reference; System.Drawing está en el GAC).

En MSDN, puede ver en qué ensamblaje "vive" cada clase. Por ejemplo, en la documentación de la clase Bitmap puedes ver:

Espacio de nombres: System.Drawing

Assembly: System.Drawing (en System.Drawing.dll)

Tenga en cuenta que en el nivel del espacio de nombres no puede encontrar la información de "Ensamblaje", porque puede agregar clases al mismo espacio de nombres desde diferentes ensamblajes.


System.Drawing encuentra en un ensamblaje separado al que debe hacer referencia.


Incluso después de agregar System.Drawing como referencia, todavía no se puede incluir en un proyecto.


La .NET Common Language Infrastructure tiene dos conceptos distintos:

  • Espacios de nombres: Prefijos para nombres de tipos como System.Drawing , que se usan para distinguir varios tipos que de otra manera tendrían el mismo nombre.
  • Ensamblados: bibliotecas de código que pueden implementarse, instalarse y versionarse por separado de otros ensamblados. Los tipos en un ensamblado pueden estar en cualquier cantidad de espacios de nombres.

Los espacios de nombres forman una jerarquía basada en separadores de punto (completo), por lo que debe pensar que los tipos en el System.Runtime.InteropServices nombres System.Runtime.InteropServices están subordinados a los del System.Runtime nombres System.Runtime . Sin embargo, hasta donde yo sé, la CLI no se preocupa por el nombre o la jerarquía de sus espacios de nombres, excepto en la medida en que hacen que sus nombres de tipos sean únicos.

Además, un ensamblaje puede contener tipos de múltiples espacios de nombres, incluso en jerarquías diferentes, y un único espacio de nombres puede contener tipos definidos en ensamblajes múltiples. Si observa la documentación de MSDN para un tipo en las bibliotecas de .NET, le dirá en qué ensamblado se encuentra ese tipo. Sin embargo, como ha señalado Paolo Falabella, MSDN no le dirá en qué ensamble está el espacio de nombres, porque el espacio de nombre único puede contener tipos de múltiples conjuntos.

En su escenario: mscorlib es un ensamblado que define algunos tipos en el espacio de nombres del System y muchos otros, como System.Runtime.InteropServices , como ha señalado. Sin embargo, los tipos que está utilizando en el espacio de nombres System.Drawing se encuentran en el ensamblado System.Drawing .

Dado que los ensamblados son la unidad de implementación y reutilización de código, Visual Studio proyecta ensamblados de referencia, no espacios de nombres, por lo que debe agregar una referencia al ensamblado System.Drawing en el proyecto de Visual Studio para su programa.

La instrucción Imports VB.NET (y su equivalente C #, la directiva using ) le permiten consultar tipos en un espacio de nombres sin tener que escribir el nombre del espacio de nombres cada vez. Es decir, con Imports System.Drawing , puede escribir Graphics en su código en lugar de System.Drawing.Graphics . Pero eso es todo lo que hace la declaración de Importaciones. En particular:

  • Imports System no crea automáticamente referencias de proyectos para cada ensamblaje del mundo que define tipos en el espacio de nombres del sistema.
  • Imports mscorlib no significa que haga referencia a todos los tipos en el ensamblado "mscorlib" por su nombre corto. Significa que puede hacer referencia a los tipos en el espacio de nombre "mscorlib" por sus nombres cortos, que no solo es completamente diferente sino que es muy poco probable que sea lo que usted desea.

En resumen: si desea acceder a GDI +, use los tipos en el espacio de nombres System.Drawing, pero ese nombre no tiene nada que ver con el nombre del ensamblado de GDI +. Microsoft eligió el nombre "System.Drawing" para el ensamblado que contiene tipos GDI +, pero podría haber elegido "gdiplus-cli", "gdi-for-dotnet" o incluso "Frobinator". Cualquiera que sea el nombre que tenga el ensamblaje, debe agregar una referencia a ese ensamblaje. Y no hace eso en su código fuente: agrega referencias de ensamblaje en su configuración de proyecto de Visual Studio.

MSDN tiene una descripción desactualizada pero aún buena de ensamblajes, espacios de nombres y las diferencias entre ellos, que pueden ser útiles.