In Java I can use, for example, " Imports java.util.* ". Can I use, for
example, " Imports System.* " instead of several different "Imports"
statements? Thank you. David

No (I found the answer by trying).

Check http://msdn2.microsoft.com/en-us/library/7f38zh8x.aspx for details
(looks like this is necessarily the full qualified name).

2070FE78-875F-413D-AB5B-486BDAB83***@microsoft.com...
Show quoteHide quote

Simply use 'Imports System'.

Well, needless to say, I'm confused! One reply is "No, you can't. I tried."
& the other is "Simply use 'Imports System' "!

So, I suppose that if I use "Imports System" , it will probably be a pretty
big file.

I wonder why I've gotten 2 different answers.

Thank you. David

Show quoteHide quote

The answer is NO

Using 'Imports System'  will not give you access to
'System.Data.SqlClient'
If you just import System, you will only get things in the System
namespace such as 'System.Int32' and 'System.Type' etc.

That's true, but it would be rather useless to import all subnamespaces of a
namespace.  Importing using the asterisk in Java will import the types
contained in the package, but it won't import other packages.

pcnerd wrote:
This comment suggests you might have a misconception about Imports in
VB.NET, because it is the same word as a Java keyword. Now, my Java
experience is pretty small, but am I right in thinking that in Java you
want to import only the minimum you need to, because importing actually
does something to the produced executable? Well, in VB.NET, Imports is
*entirely* syntactic sugar - all it does is allow us to use the names
of things from our References without fully qualifying them. As the
docs put it: "Importing does not take the place of setting a reference.
It only removes the need to qualify names that are already available to
your project."

For example, once we reference, say, System.dll, everything in there is
available to us whether we use Imports System or not; all the Imports
line does is allow us to refer to System.Uri as simply 'Uri' in our
code.

Note that many commonly-used namespaces are imported automatically in
newly-created projects, at the project level, so we often don't need
any Imports statements in individual files.


Of course, if you knew all this already, great! :)

The resulting file will be /no bigger/, regardless of how many Imports
statements you use, because the Imports statement doesn't do what you
think it does.

It does NOT give your application "access" to anything it didn't have
before.  That's does by adding References to other assemblies and no;
the Referenced assemblies are not compiled into your finished program;
they become run-time dependencies.

Imports /only/ allows you, in your code, to /type less/, as in

(without Imports)
Console.Writeline( _
     System.Reflection.MethodBase.GetCurrentMethod().Name _
     )

or (with Imports)

Imports System.Reflection.MethodBase
.. . .
Console.Writeline( _
     GetCurrentMethod().Name _
     )

When the code gets compiled, the fully qualified names get used
regardless of what you typed, so the size of your executable is unaffected.

HTH,
    Phill  W.

dotnet activex equivalent?
Is microsoft awaring VB.Net too hard to maintain?
Opacity on form
Another Printing Question
Transferring data between datatables and between datareader and datatable
Visual Studio .NET 2005 using Web Application Project
Retrieving the System date and time settings
Creating an array of objects when the object type is not known at design time
SQL update statment, using ACCESS yes/no
Refreshing datagridview