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
