Visual Basic, why can't I import "System.Drawing" when my only link is "System"?

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

To reproduce my problem:
1. Create a new project in Visual Studio 10 using the Visual Basic class library template.
2. Add "Import System.Drawing" and "Imports System.Runtime.InteropServices" at the beginning.
3. Remove all links except the "System" in the Links panel of the project properties.

Result: Visual Studio cannot find "System.Drawing", but it can find "System.Runtime.InteropServices". "System.Drawing" fully complies with the requirements, so the system should be able to find it in the specified "System".

Thoughts: It seems that the "System" and "System.Drawing" are different namespaces (or containers?), So why is not the qualification ".". Job? Makes a "." something other?

The "system" is also located in "mscorlib", but is it the namespace that is being used or is it different?

"Microsoft.VisualBasic" is also listed in the imported namespaces, but there is no link to it. How was this found? Where is the Imported Namespaces list?

Linking to any related information from the MSDN library will definitely be helpful. I have been looking at this for a while, but I cannot understand why "System.Drawing" is not imported.

+7
source share
4 answers

The .NET Common Language Infrastructure has two different concepts:

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

Namespaces form a hierarchy based on delimiters with a full stop (period), so you should think that the types in the System.Runtime.InteropServices subordinate to those in the System.Runtime . However, as far as I know, the CLI does not care about the name or hierarchy of your namespaces, unless they make your type names unique.

In addition, an assembly can contain types from several namespaces, even in different hierarchies, and a single namespace can contain types defined in several assemblies. If you look at the MSDN documentation for a type in .NET libraries, it will tell you which particular assembly is included. However, as Paolo Falabella noted, MSDN will not tell you which assembly contains a namespace, since 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 that you use in the System.Drawing namespace are located in the System.Drawing assembly.

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

The VB.NET Imports (and its C # equivalent, using ) allows you to refer to types in the namespace without having to call the namespace name each time. That is, with Imports System.Drawing , you can write Graphics in your code instead of System.Drawing.Graphics . But this is all the Imports operator. In particular:

  • Imports System does not automatically create project references for every assembly in the world that defines types in the System namespace.
  • Imports mscorlib does not mean that you refer to each type of assembly "mscorlib" by its short name. This means that you can refer to types in the mscorlib namespace by their short names, which are not only completely different, but are unlikely to be what you want.

Bottom line: if you want to access GDI +, then you use types in the System.Drawing namespace, but this name has nothing to do with the GDI + assembly name. Microsoft chose the name "System.Drawing" for the assembly, which contains GDI + types, but it could choose "gdiplus-cli", "gdi-for-dotnet", or even "Frobinator". No matter what name this assembly has, you must add a link to this assembly. And you do not do this in your source code - you add assembly references in the configuration of your Visual Studio project.

MSDN has an outdated but still good description of assemblies, namespaces, and the differences between them that may be useful.

+14
source

The System.Drawing namespace "lives" in another dll, which is not originally mentioned in the template project for the class library. You will need to add a link to System.Drawing (right-click on the project → add link, System.Drawing to the GAC).

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

Namespace: System.Drawing

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

Note that at the namespace level, you cannot find Assembly information because you can add classes to the same namespace from different nodes.

+6
source

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

+1
source

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

0
source

All Articles