System References/Imprts

[gwboolean]

I do not recall what the terminology is for the imports below (I just call them references). However, what I would like to know is this. Do I need to put these in every form/Class that I have, or is it just sufficient for these to be in one form in a project? My own thought is that only one would be necessary in my main menu since it is never more than hidden until the application is closed. Also, if I reference these in the project references I would assume that I need not even have them in the code?

Imports System
Imports System.Diagnostics

[si_the_geek]

Those are Imports, and are very different to References.

You need a reference to use something at all, and is basically linking to a DLL (or similar).

Using Imports just saves typing... so instead of having to write System.Diagnostics.ClassName you can write ClassName

[Sitten Spynne]

These are called "Imports Statements".

They only apply to the file in which they are located. So if you have more than one code file in a project, you might have to add "Imports System.Diagnostics" in each of them. Or you might not. You only need an Imports statement if you want to use types from that namespace, and you can still fully-qualify names without using an Imports statement.

Let's get more detailed, since you seem a little confused.

First, you need to understand what a "fully qualified name" is. It actually means 2 things. To .NET, "Fully Qualified Name" has a lot of components. It's got a namespace, type name, DLL name, version, and often a public key token. So the real "Fully Qualified Name" for Button is something like:

System.Windows.Forms.Button, System.Windows.Forms.dll, Version=2.0.0.0, PublicKeyToken=<a long string>

Most of the time when an expert says "fully qualified name" they mean just the namespace and the type name. Button is a type in the namespace System.Windows.Forms, so we would usually mean "System.Windows.Forms.Button" when we talk about its "fully qualified name".

Note that a namespace and a DLL name are not the same. Lots of System types live in a DLL named "mscorlib.dll". Namespaces are actually something you can put in your code. This is a little confusing, because VB tries to hide them from you. Usually your files automatically have a namespace of your project name. So if your project is named "WindowsApplication1", and we have this class:

Public Class Example

End Class

The fully-qualified name of this type is "WindowsApplication1.Example" in VB projects, unless you mess with the settings.

So let's say you have exactly this file, with no imports, in that project named WindowsApplication1, and you haven't referenced System.Windows.Forms.dll:

Public Class Form1
    Inherits Form

End Class

When the compiler gets to "Form", it doesn't know what that word means. It will first look for any class named "WindowsApplication1.Form". If it can't find that, it will start using any namespaces that have been imported. Since this file has no Imports statements, there's nothing to try, and the compiler complains it doesn't know what type "Form" means.

So let's say you add the reference, but don't add an Imports statement. Nothing really changes. The only namespace the compiler will check is WindowsApplication1, and System.Windows.Forms.dll does not contain a type named "WindowsApplication1.Form". We know you meant "System.Windows.Forms.Form", but you haven't told the compiler that yet.

(Visual Studio is pretty smart, and at this point usually points out it can see System.Windows.Forms.Form and will ask if you want to add that Imports statement. But it's important to note that it never changes your code without asking first.)

Now let's say you add the Imports statement without adding the reference:

Imports System.Windows.Forms

Public Class Form1
    Inherits Form

End Class

The compiler tries to find "WindowsApplication1.Form" first, and can't find it. Next it tries to find "System.Windows.Forms.Form", but since the reference wasn't added it can't find it. So it complains.

If you add the reference AND the Imports statement, the compiler will try "System.Windows.Forms.Form" and find it in System.Windows.Forms.dll.

Things get confusing if you have BOTH WindowsApplication1 and System.Windows.Forms.Form. Usually in that case, Visual Studio asks you to fully-qualify the type so it knows which one you want. There are some other tricks to deal with that, but generally you just shouldn't name your types the same thing as very common MS types.

This can be sort of blury in VB because it automatically adds some Imports to each file. If a namespace is in the list of automatically-imported namespaces, the compiler acts like the Imports statement is in every file. If you're curious which ones are imported, or want to edit the list, look in your project properties under the "References" tab. The bottom half of the page is a big list of namespaces that will be automatically imported.

[jmcilhinney]

I have a feeling that I have already directed you this way before, although I may be wrong. I suggest that you follow the Blog link in my signature below and check out my post on Assemblies & Namespaces.

EDIT: http://jmcilhinney.blogspot.com.au/2...importing.html