asp.net|区别 If you're having conceptual difficulties with the Import and Assembly directives, you're not the only one. Read this article to find out about the use of .NET components in ASP.NET and forget you ever had doubts.

What Has Changed Compared to ASP Classic?
If you've developed Active Server Pages you will be familiar with the following notation:

Components in ASP Classic
<script runat="server" language="VBScript">
  Dim fso
  Set fso = Server.CreateObject("Scripting.FileSystemObject")
</script>
To create an instance of a class we use the CreateObject method of the Server object. In the above code the variable fso is first declared and then assigned a reference to the FileSystemObject object that can be found in the Scripting library. For this to work it is necessary that the corresponding DLL is installed and registered on the server. The registration of the FileSystemObject object occurred automatically when the VBScript runtime was installed. If you want to use a 3rd-party component or one you created yourself, you will need to take care of installing and registering it.

Let's now have a look at how the FileSystemObject object, if it existed, would be instantiated in ASP.NET:

ASP.NET Equivalent (VB.NET)
<script runat="server" language="VB">
  Dim fso As Scripting.FileSystemObject = New Scripting.FileSystemObject()
</script>
ASP.NET Equivalent (C#)
<script runat="server" language="c#">
  Scripting.FileSystemObject fso = new Scripting.FileSystemObject();
</script>
As you can see, there are some differences to be found. The most important are:

VBScript has been dropped and replaced by the fully-fledged VB.NET (a.k.a. VB 7.0).
While declaring a variable you can specify its type and initialize it.
To refer to a class, the notation Namespace[.SubNamespace].Class notation is used. In the above example we are referring to the FileSystemObject class that can be found in the Scripting namespace. Note that such namespace doesn't exist in the .NET Framework and therefore the above code will not work. On the other hand we could create our own Scripting namespace and define the FileSystemObject class in it.

What is a Namespace?
In the previous section the word "namespace" has been used. By means of namespaces you can systematize classes into logically related units. As a rule, you will cluster classes that provide similar functionality or have a similar context. For instance the System.IO namespace contains classes that are used to deal with Input-Output operations like reading, writing or deleting files. Note that similar functionality and/or similar context is not a formal requirement. You are free to organize your namespaces along any rules, even no rules.



Referring to .NET Components
As already noted, the first ASP.NET example was there for didactical reasons--it wouldn't work. Let's now have a look at a working example:

Creating the Message object (VB.NET)
<% Assembly Name="System.Messaging.dll" %>
<script runat="server" language="VB">
  Dim myDir As System.Messaging.Message = New System.Messaging.Message()
</script>
Creating the Message object (C#)
<% Assembly Name="System.Messaging.dll" %>
<script runat="server" language="C#">
  System.Messaging.Message myDir = new System.Messaging.Message();
</script>
The Assembly directive links an assembly to the current page, making all of the classes, interfaces and structures defined in the assembly available for use. In our example we are binding the System.Messaging.dll assembly. This assembly contains the System.Messaging namespace the classes of which provide access to the .NET Framework messaging functionality. We create an instance of the Message class that provides access to Message Queuing message. If we were to create the Message object in a code-behind file, here's what we would end up doing:

Creting the Message object in a code-behind file (VB.NET)
Public Class myPage
Inherits System.Web.UI.Page
  Dim myDir As System.Messaging.Message = New System.Messaging.Message()
End Class
Creting the Message object in a code-behind file (C#)
public class myPage : System.Web.UI.Page {
  System.Messaging.Message myDir = new System.Messaging.Message();
}
Note that if we wanted to compile the class, we would need to provide the compiler with the reference to the System.Messaging.dll and the System.Web.dll file. Assuming we save the class in a file named mypage.vb or mypage.cs for the VB.NET or the C# version respectively, the compilation statement would look like this:

Compiling the code-behind class
vbc mypage.vb /r:System.Messaging.dll /r:System.Web.dll
csc mypage.cs /r:System.Messaging.dll /r:System.Web.dll
The /r:System.Messaging.dll and /r:System.Web.dll options of the compiler play the same role as the Assembly directive on a web form.

What Is an Assembly?
An assembly forms a logical unit of functionality. It is the fundamental, self-describing unit of deployment, version control, reuse, activation scoping, and security permissions. It contains the assembly manifest, which represents all the metadata needed to specify the version requirements, security identity, and other information.



Importing Namespaces
You will have noticed, that whenever we refer to the Message object, we always need to provide the full namespace path (another words fully qualify the class name). It isn't hard to imagine that after a while this could be cumbersome and unnecessarily inflate the code. Fortunately, there is a way to define the namespace path once per page thus saving a few keystrokes:

Importing an assembly (VB.NET)
<% Assembly Name="System.Messaging.dll" %>
<% Import Namespace="System.Messaging" %>
<script runat="server" language="VB">
  Dim myDir As Message = New Message()
</script>
Importing an assembly (C#)
<% Assembly Name="System.Messaging.dll" %>
<% Import Namespace="System.Messaging" %>
<script runat="server" language="C#">
  Message myDir = new Message();
</script>
Our code-behind class could be rewritten as follows:

Importing an assembly in a code-behind file (VB.NET)
Imports System.Web.UI
Imports System.Messaging
Public Class myPage
Inherits Page
  Dim myDir As Message = New Message()
End Class
Importing an assembly in a code-behind file (C#)
using System.Web.UI;
using System.Messaging;
public class myPage : Page {
  Message myDir = new Message();
}
By means of the Import directive as well as the Imports or the using statements we can specify the namespace path to the classes we use. Having done that we can later refer to the classes without fully qualifing the namespace path. Note that if both the System.Web.UI and the System.Messaging namespace had a Message class, we would have to qualify the class name.

It is very important to be aware of what importing a namespace does and what it doesn't. Its only, albeit handy, use is to save the programmer some keystrokes and bestow the code with better readability. It alone is not sufficient to make classes inside of a namespace available to the code. The directive that actually links the namespace to the page is the Assembly directive or the /r compiler option we have already talked about.

Automation Through Configuration
Using the Assembly directive is not the only way to link assemblies to a web form. Assemblies can be automatically linked to pages within an application. Such assemblies do not require the Assembly directive. The automatic linking is enabled by means of the <assemblies> section of the configuration file (config.web):

Automatic linking in the config.web file
<configuration>
  <compilation>
    <assemblies>
      <add assembly="System.Messaging"/>
      <add assembly="*"/>
    </assemblies>
  </compilation>
</configuration>
The asterisk instructs ASP.NET to link every assembly within an application's private assembly cache. By means of the <add> element you can link any namespace in that scope.

What is the application's private assembly cache?
The documentation defines the application's private assembly cache is as the \bin sub-directory of the application plus the Microsoft .NET Framework install folder. My tests, though, have proven that only the \bin sub-folder is considered to be the private cache--in the sense that only for that folder will the asterisk wildcard work.



Important note: If you have skipped the box above, there is one thing worth knowing: the asterisk in the <add> element will only link assemblies which are located in the \bin sub-folder of the application.

With the installation of the .NET Framework there comes a default config.web file. It automatically adds the following assemblies:

mscorlib
System
System.Data
System.Diagnostics
System.Drawing
System.Net
System.Text.RegularExpressions
System.Web
System.Web.Services
System.Xml
System.Xml.Serialization
Microsoft.Comservices
*
You can view the default config.web file on your system to confirm that. The following namespaces are automatically imported:

Microsoft.VisualBasic
System
System.Collections
System.Text
System.Text.RegularExpressions
System.Web
System.Web.Caching
System.Web.SessionState
System.Web.Security
System.Web.UI
System.Web.UI.WebControls
System.Web.UI.HtmlControls
Unfortunately I wasn't able to determine where the automatic import is set. If you happen to know this, please drop me a line.