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

Question

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 la biblioteca de clases de Visual Basic.
2. Agregue "Imports System.Drawing" e "Imports System.Runtime.InteropServices" al principio.
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 (¿o contenedores?) Distintos, entonces ¿por qué la calificación no "." ¿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.

Answer 1

la infraestructura de .NET Common Language tiene dos conceptos distintos:

• espacios de nombres: prefijos de nombres de tipos, tales como System.Drawing, que se utilizan para distinguir múltiples tipos, que de otra manera tendrían el mismo nombre.
• Assemblies: 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.

espacios de nombres forman una jerarquía basada en el punto (punto) separadores - por lo que se supone que pensar que los tipos en el espacio de nombres System.Runtime.InteropServices están subordinados a los de la System.Runtime espacio de nombres. 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 varios espacios de nombres, incluso en jerarquías diferentes, y un solo espacio de nombres puede contener tipos definidos en ensamblajes múltiples. Si mira la documentación de MSDN para un tipo en las bibliotecas .NET, le dirá en qué ensamblaje está ese tipo. Sin embargo, as Paolo Falabella has pointed out, MSDN no le dirá en qué ensamblado se encuentra un espacio de nombres, porque un solo espacio de nombres puede contener tipos de múltiples ensambles.

En su escenario: mscorlib es un ensamblaje que define algunos tipos en el espacio de nombres System y muchos otros, como System.Runtime.InteropServices, como ha indicado. Sin embargo, los tipos que está utilizando en el espacio de nombres System.Drawing se encuentran en el ensamblaje 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.

The VB.NET Imports statement (y su equivalente C#, la using directive) vamos que se refieren a los tipos en un espacio de nombressin 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 hace la declaración de Importaciones. En particular:

• Imports System no crea automáticamente las referencias del proyecto a todas las asambleas en el mundo que pasa a definir los tipos en el espacio de nombres System.
• 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.

Conclusión: si desea acceder a GDI +, utilice los tipos en el espacio de nombres System.Drawing, pero ese nombre no tiene nada que ver con el nombre del ensamblado 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 eso no se hace en el código fuente - you add assembly references in your Visual Studio project configuration.

MSDN has an outdated but still good description of assemblies, namespaces, and the differences between them, which you may find helpful.

Answer 2

System.Drawing está en un conjunto separado al que debe hacer referencia.

Answer 3

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

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

Espacio de nombres: System.Drawing

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

Tenga en cuenta que at the namespace level no puede encontrar la información de "Ensamblaje", porque puede agregar clases al mismo espacio de nombres de diferentes conjuntos.

Answer 4

Incluso después de añadir System.Drawing como referencia, todavía no puede incluirse en un proyecto.