@import vs. @assembly

[Bruce W. Roeser]

All,

I'm reading a book by Charles Petzold (Programming VS.Net). Pretty good
content but am confused about the difference. From the text:

----------------------------------------------------------------------------------------------------------------------------------------------------------
The @ Import Directive
Next to @ Page, the directive that ASP.NET programmers use the most is @
Import. The @ Import directive is ASP.NET's equivalent of C#'s using
directive. Its purpose is to import a namespace so that the types in that
namespace are known to the compiler. You need @ Import any time you use an
FCL data type that's defined in a namespace that ASP.NET doesn't import by
default. For example, the statement

<%@ Import Namespace="System.Data" %>makes all the data types defined in
System.Data available to a Web form.

What namespaces does ASP.NET import by default? Here's a complete list:

a.. System

b.. System.Collections

c.. System.Collections.Specialized

d.. System.Configuration

e.. System.IO

f.. System.Text

g.. System.Text.RegularExpressions

h.. System.Web

i.. System.Web.Caching

j.. System.Web.Security

k.. System.Web.SessionState

l.. System.Web.UI

m.. System.Web.UI.HtmlControls

n.. System.Web.UI.WebControls

Because System.Data isn't imported automatically, you must import it
yourself if you want to use System.Data types (for example, DataSet) in a
Web form. Otherwise, you'll receive an error message the first time ASP.NET
attempts to compile the page. System.Web.Mail is another example of a
commonly used namespace that isn't imported automatically. Look back at
Chapter 3's SendMail program (Figure 3-7), and you'll see an @ Import
statement importing System.Web.Mail on the very first line of the ASPX file.

Unlike @ Page, @ Import can appear multiple times in a Web page. The
following statements import three namespaces and are often used together in
ASPX files that access SQL Server databases:

<%@ Import Namespace="System.Data" %>
<%@ Import Namespace="System.Data.SqlClient" %>
<%@ Import Namespace="System.Data.SqlTypes" %>The @ Assembly Directive
The @ Import directive identifies namespaces containing an application's
data types; @ Assembly identifies assemblies. The .NET Framework class
library is implemented in a series of single-file assemblies: Mscorlib.dll,
System.dll, and others. If ASP.NET is to compile your page, it must know
which assemblies the page references so that it can provide that information
to the compiler. The following assembly names are provided to the compiler
by default and therefore require no @ Assembly directive:

a.. Mscorlib.dll

b.. System.dll

c.. System.Data.dll

d.. System.Drawing.dll

e.. System.EnterpriseServices.dll

f.. System.Web.dll

g.. System.Web.Services.dll

h.. System.Xml.dll

These assemblies include the data types that Web forms are most likely to
use. But suppose you want to use the FCL's
System.DirectoryServices.DirectorySearcher class in a <script> block to
perform a query against Active Directory. Because DirectorySearcher lives in
an assembly (System.DirectoryServices.dll) that ASP.NET doesn't reference by
default, its use requires an @ Assembly directive. In the following example,
@ Import is required also because DirectorySearcher is defined in a
nondefault namespace:

<%@ Import Namespace="System.DirectoryServices" %>
<%@ Assembly Name="System.DirectoryServices" %>It's coincidental that the
namespace name and assembly name are one and the same; that's not always the
case. Note that an assembly name passed to @ Assembly must not include the
filename extension (.dll). In addition, the list of "default" assemblies can
be changed by editing a machine-wide configuration file named Machine.config
or augmented by dropping a Web.config file containing an <assemblies>
section into an application root. Like @ Import, @ Assembly can appear
multiple times in a Web page.

----------------------------------------------------------------------------------------------------------------------------------------------------------
My question - what's the point of having the two directives? It seems that
@ Import provides the information needed to reference the FCL classes. Why
do you, then, need to specify an Assembly, too? Isn't that redundant?

TIA,

-bruce

 

[Scott Allen]

Hi Bruce:

You need the @ Assembly attribute to tell the compiler where the types
live. The compiler must know where the compiled code exists (what dll)
for the types you need to use.

@ Import is not required. You could reference a class like:

System.Data.SqlClient.SqlConnection connection;

But by importing the System.Data.SqlClient namespace, you can save
some typing and use:

SqlConnection connection;

The SqlConnection class (from the System.Data.SqlClient namespace)
could live in an assembly called foo.dll (it doesn't, but it could).

Since there is no relation between assembly name and the namespace(s)
it contains, the @ Assembly directive is still required to point the
compiler to the right assembly.

I'm not Petzold, so I hope this helps

 

[Bruce W. Roeser]

Hi Scott,

Ahh ... OK, that makes a little more sense. I'm just now starting to learn
about ASP.Net. So far I've been doing mostly WinForms development in C#
where you don't have to do the dual-reference like that; you can just say
#using <whatever> and the fixups are taken care of. Apparently (according
to what you and Petzold are saying) the #using (that is @imports) do
essentially the same thing as far as coding is concerned but ASP.Net can't
infer which DLL to load from the namespace alone. I guess the C# compiler
for WinForms understands by itself what DLL to pull in based only on the
namespace and reference in your code - right?

Thanks,

-bruce

 

[Scott Allen]

Hi Paul:
For WinForms there is Project -> Add Reference to tell the compiler to
add another assembly. You can see the referenced assembly in the
Solution Explorer window underneth the project references node. the
#using directive and @ Imports do the same job, yes.

 

[Bruce W. Roeser]

Many thanks, Scott. Yeah, I think I get it. I guess I expected it to be a
little more automatic - I.E. if the namespace reference works to allow me to
reference an object I would have thought this would also describe (lower
level, perhaps) to the compiler where to find the code associated with it.

-bruce