vbc

  • Thread starter Thread starter David Chipping
  • Start date Start date
D

David Chipping

I have run into the following situation, of which I don't understand
and would appreciate someone filling me in on hopefully an obvious
detail im looking over:

A compilation example (that compiles) that imports System but does not
reference System.dll:

vbc /rootnamespace:xxx /target:library
/r:System.Windows.Forms.dll,System.Drawing.dll /imports:System *.vb

Would this be allowed only if the code never used System, but was
simply just importing it for no reason at all?

Cheers,

-David
 
David said:
I have run into the following situation, of which I don't understand
and would appreciate someone filling me in on hopefully an obvious
detail im looking over:

A compilation example (that compiles) that imports System but does not
reference System.dll:

vbc /rootnamespace:xxx /target:library
/r:System.Windows.Forms.dll,System.Drawing.dll /imports:System *.vb

Would this be allowed only if the code never used System, but was
simply just importing it for no reason at all?

Cheers,

-David
Click to expand...

The Import directives (or the import switch your using) are just there
to provide a short-hand. They provide a means for you to provide a
partial class name, and for that to be resolved into a full class name.
E.g., if you have a variable within you project files which is declared
to be of type Drawing.Font, it is the imports which helps the system to
resolve this to System.Drawing.Font.

I believe that the imports are only used by the compiler - I believe
all class names are full class names by the time the Assembly is
output.

Damien
 
Damien said:
The Import directives (or the import switch your using) are just there
to provide a short-hand. They provide a means for you to provide a
partial class name, and for that to be resolved into a full class name.
E.g., if you have a variable within you project files which is declared
to be of type Drawing.Font, it is the imports which helps the system to
resolve this to System.Drawing.Font.

I believe that the imports are only used by the compiler - I believe
all class names are full class names by the time the Assembly is
output.

Damien
Click to expand...

The other thing to say, of course, is that any and every DLL can
contain classes within the System namespace. System.dll only actually
contains Three classes directly under the System namespace (Uri,
UriBuilder and UriFormatException). Most of the classes directly within
the System namespace are provided by mscorlib.dll, which is always
"referenced" by your projects anyway.

Damien
 
Thanks very much for the reply, I think what was actually confusing me
more, was not what the Import switch actually did, but the almost
automatic like referencing of the compiler, which seems to be able to
reference almost all System.* and Microsoft.* assemblies automatically.

Is this hard coded in the compiler, or is it doing something else to
resolve these references, looking in the GAC, or in the registry?

Thanks very much,

-David
 
David said:
Thanks very much for the reply, I think what was actually confusing me
more, was not what the Import switch actually did, but the almost
automatic like referencing of the compiler, which seems to be able to
reference almost all System.* and Microsoft.* assemblies automatically.

Is this hard coded in the compiler, or is it doing something else to
resolve these references, looking in the GAC, or in the registry?

Thanks very much,

-David
Click to expand...

Well, like I said, a lot of classes are provided by mscorlib.dll, which
you are automagically referencing in every project. It contains the
Microsoft.Win32 Registry classes, the basic value types +
AppDomain/Assembly/GC and the basic exceptions within System, plus
stuff for Collections, Globalization, IO, Reflection, Resources,
CompilerServices, InteropServices, Remoting, Serialization,
Crypotgraphy, Threading, plus bits and bobs in other namespaces. Quite
a lot really.

If you add a reference to System.dll, you don't actually get much added
to the System namespace, but a lot more of the Microsoft.Win32 stuff
turns up, plus various stuff deeper inside the System namespace.
System.Drawing only adds stuff inside the System.Drawing namespace and
a couple of sub-namespaces.

Not sure about System.Windows.Forms - I'm in the process of rebuilding
my machine from it crashing hard on Thursday, and I've only pulled one
..NET project over from SourceSafe so far (the one I need to work on at
the moment). The tool I'm using to give you all this info is the Object
Browser within Visual Studio - if you have Visual Studio, you can open
this with Ctrl-Alt-J. I find it useful for exploring which classes are
implemented by which assemblies.

And I've got no idea about anything else that might get forced in by
the compiler - I've never had to delve that deep.

Hope that's been of some help,

Damien
 
Damien,

It's been useful, thanks. I'm just not happy until I understand the
complete process it takes, just so I can be sure. It's always a good
excuse to delve a bit deaper anyway :)

Cheers,

-David
 
Back
Top