Visual Basic, why can't I import “System.Drawing” when my only reference is “System”?

Question

In Visual Studio 10 - Visual Basic, why can't I import "System.Drawing" when my only reference is "System"? I can import "System.Runtime.InteropServices".

To reproduce my problem:
1. Create a New Project in Visual Studio 10 with Visual Basic Class Library template.
2. Add "Imports System.Drawing" and "Imports System.Runtime.InteropServices" at the beginning.
3. Remove all references except "System" in the References pane of the project properties.

Result: Visual Studio cannot find "System.Drawing" but it can find "System.Runtime.InteropServices". "System.Drawing" is fully qualified so the system should be able to find it inside the referenced "System".

Thoughts: It appears "System" and "System.Drawing" are distinct namespaces (or containers?) so why doesn't qualification "." work? Does "." represent something else?

"System" is also in "mscorlib" but is that the namespace which is used or is it another?

"Microsoft.VisualBasic" is also listed in the imported namespaces but there is not a reference to it. How was it found? Where is the "Imported namespaces" list populated from?

A link to any related info from the MSDN library would definitely be helpful. I have been looking through it for a while but cannot understand why "System.Drawing" is not imported.

Answer 1

The .NET Common Language Infrastructure has two distinct concepts:

• Namespaces: Prefixes for type names such as System.Drawing, which are used to distinguish multiple types which would otherwise have the same name.
• Assemblies: Libraries of code which can be deployed, installed, and versioned separately from other assemblies. The types in an assembly may be in any number of namespaces.

Namespaces form a hierarchy based on full-stop (dot) separators - so you are meant to think that the types in the System.Runtime.InteropServices namespace are subordinate to the ones in the System.Runtime namespace. However, as far as I know, the CLI does not care about the name or hierarchy of your namespaces, except insofar as they make your type names unique.

Furthermore, an assembly can contain types from multiple namespaces, even ones in different hierarchies, and a single namespace can contain types defined in multiple assemblies. If you look at the MSDN documentation for a type in the .NET libraries, it will tell you what assembly that type is in. However, as Paolo Falabella has pointed out, MSDN will not tell you what assembly a namespace is in, because a single namespace can contain types from multiple assemblies.

In your scenario: mscorlib is an assembly that defines some types in the System namespace and many others, such as System.Runtime.InteropServices, as you noted. However, the types you are using in the System.Drawing namespace are located in the System.Drawing assembly.

Because assemblies are the unit of code deployment and reuse, Visual Studio projects reference assemblies, not namespaces, and so you must add a reference to the System.Drawing assembly in the Visual Studio project for your program.

The VB.NET Imports statement (and its C# equivalent, the using directive) let you refer to types in a namespace without having to type out the namespace name every time. That is, with Imports System.Drawing, you can write Graphics in your code instead of System.Drawing.Graphics. But that is all the Imports statement does. In particular:

• Imports System does not automatically create project references to every assembly in the world that happens to define types in the System namespace.
• Imports mscorlib does not mean you reference every type in the "mscorlib" assembly by its short name. It means you can reference types in the "mscorlib" namespace by their short names, which is not only entirely different but very unlikely to be what you want.

Bottom line: if you want access to GDI+, then you use the types in the System.Drawing namespace, but that name has nothing to do with the GDI+ assembly's name. Microsoft chose the name "System.Drawing" for the assembly that contains GDI+ types, but it could have chosen "gdiplus-cli", "gdi-for-dotnet", or even "Frobinator". Whatever name that assembly has, you have to add a reference to that assembly. And you don't do that in your source code - 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

The System.Drawing namespace "lives" in another dll that is not referenced initially in the template project for a class library. You will have to add a reference to System.Drawing (right click on the project -> add reference; System.Drawing is in the GAC).

On the MSDN, you can see in what assembly each class "lives". For example, in the documentation for the Bitmap class you can see:

Namespace: System.Drawing

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

Note that at the namespace level you can't find the "Assembly" information, because you can add classes to the same namespace from different assemblies.

Answer 3

System.Drawing is in a separate assembly you need to reference.

Answer 4

Even after adding System.Drawing as a reference, it still cannot be included in a project.