VB.NET classes, imports, and namespaces

  • Thread starter Thread starter douglass_davis
  • Start date Start date
Assuming VS.NET check the project properties. You'll find a list of
automatically imported namespaces...
 
Is the whole System namespace automatically imported?
Click to expand...

Using Visual Basic, you do get an automatic Import for System.

But that /only/ includes the stuff in System itself.
It /doesn't/ include all the "subsections" of System, like System.Data,
System.Xml, etc., etc.

HTH,
Phill W.
 
Yes and No,

If you create a notepad file code.vb with a main method you will find that
Console.WriteLine will cause a compiler error unless you add Imports
System.

Visual Studio automatically adds a few namespaces and references to common
assemblies depending on what project you create.

However, System.dll is always included when you compile so no need to add
a reference to it.
 
Morten said:
Yes and No,

If you create a notepad file code.vb with a main method you will find that
Console.WriteLine will cause a compiler error unless you add Imports
System.

Visual Studio automatically adds a few namespaces and references to common
assemblies depending on what project you create.

However, System.dll is always included when you compile so no need to add
a reference to it.
Click to expand...


Fascinating.

I guess VB.NET tries to hide complexity from you. But, i am curous, at
what point do these namespaces get added? Does the simple fact that
the System.dll is included mean that the IDE automatically knows that a
String is a System.String? Or, is it through a command line option when
it compiles? Through some import code it automatically adds to the
code you write?

I know it works, but I'm just curious, for the VB.NET experts out
there, at what point does the magic happen?
 
It's not really a feature of vb.net rather than .Net framework, and the
same applies for C#.

System.dll gets added automatically because ALL .Net programs use it.
There is a huge difference in compiler references from 1.1 to 2.0 and the
compiler in 2.0 seems to recognize what dll to include. For instance, the
code below will compile under 2.0 but not 1.1, using the command line "vbc
code.vb"

Imports System.Drawing

Class Test

Shared Sub Main()

Dim b as new Bitmap(10, 10)

End Sub

End Class

In .Net 1.1 you would need "vbc /reference:System.Drawing.dll test.vb"

In addition to making life easier with "smart" compilers and namespaces,
there are shortcuts.

There is no such thing as a System.Integer, yet Dim i as Integer will work
fine. Nor is Integer found in any other namespace either, but vb.net asa
few aliases. Integer is an alias for System.Int32 (or possible
System.Int64 on 64-bit systems). C# would use int as an alias for
System.Int32

When you type String, Visual Studio and compilers will browse through a
table of keywords and all referenced namespaces. If it finds String
defined it will use it. If it finds String defined several places it
won't know which one to use. The code below illustrates this with Timer

Imports System.Windows.Forms
Imports System.Timers

Class Test

Shared Sub Main()

Dim t as new Timer()

End Sub

End Class

Since the Timer class is defined in both System.Timers.Timer and
System.Windows.Forms (and they are different timers) you will have to
either remove the wrong namespace, use the fully qualified class name (ie
System.Timers.Timer) or define a new alias (shown below)

Imports System.Windows.Forms
Imports MyTimer = System.Timers.Timer

Class Test

Shared Sub Main()

Dim t as new MyTimer()

End Sub

End Class


Welcome to the wonderful world of .Net Framework :)
 
Morten Wennevik said:
It's not really a feature of vb.net rather than .Net framework, and the
same applies for C#.
Click to expand...

No, not quite. While certain *assemblies* are added automatically
(depending on csc.rsp), *namespaces* are never used automatically in
C#. That depends *solely* on the source code.
 
Back
Top