在ASP.NET中使用.NET组件

很多人在 @Import 和 @Assembly 页面标识的时候感到困惑，本文将为你解开这些疑问，告诉你如何来使用.NET的组件。

和ASP中的类相比较有什么改变？

如果你以前曾经开发过ASP程序，那你应当是非常熟悉下面的一段代码了：

<script runat="server" language="VBScript">
Dim fso
Set fso = Server.CreateObject("Scripting.FileSystemObject")
</script>

上面的代码告诉我们在ASP当中需要使用Server对象的CreateObject方法来建立一个类实例。上面的代码中，首先声明了变量fso，之后我们将变量fso赋于FileSystemObject的对象（FileSystemObject对象可以在Scripting这个库中找到）。如果想要上面的ASP代码得以正常运行，我们必须确定相关的DLL文件已经被安装并且注册到服务器。当VBScript运行库被安装的时候，FileSystemObject对象是会被自动注册的。但是如果你想使用第三方开发的组件或者使用你自己创建的组件，你就需要小心安装并且注册你的组件了。
接下来让我们来看看，假设在ASP.NET中也存在FileSystemObject这个对象的话，我们应当如何来实例化它：

使用VB.NET ：
<script runat="server" language="VB">
Dim fso As Scripting.FileSystemObject = New Scripting.FileSystemObject()
</script>

使用C#:
<script runat="server" language="c#">
Scripting.FileSystemObject fso = new Scripting.FileSystemObject();
</script>

正如你所看到的一样，在ASP.NET中实例化类是同ASP有所不同的。其中重要的不同点有：

在ASP.NET中已经不再可以使用VBScript语言了，而是被功能强大的VB.NET所代替了
在ASP.NET当中，在你声明一个变量的同时，可以指定它的类型并且初始化这个变量
为了引用一个类，需要使用这样的表示方法：名称空间[.子名称空间].类。
在上面的例子当中，我们引用了FileSystemObject这个类，而FileSystemObject这个类可以在名称空间Scripting中找到。需要注意的是，上面的名称空间实际上只是我们假设的一个名称空间，它并不存在于.NET的架构当中，所以上面的代码实际上是无法运行的。换句话来说就是，我们需要自己建立Scripting这个名称空间并且在这个名称空间当中定义FileSystemObject这个类。

什么是名称空间？

在前面的章节当中我们已经使用过“名称空间”这个词。利用名称空间你可以将多个类组成在逻辑上相关的一些单元。通常，你会将一些提供相似功能或者具有相似状态的类聚合在一起。比如名称空间System.IO的一个实例就包含了那些用来处理输入和输出操作（比如：读、写、删除文件）的类。值得注意的是，名称空间当中的类要具有类似的功能或者类似的状态并不是一个必须的要求。你可以按照任何规则自由的组织你自己的名称空间，甚至可以没有任何规则。

引用.NET组件

应当注意到了，我们给出的第一个ASP.NET的例子只是用来教学演示的---它是无法运行的。现在让我们来看一个能够正常运行的实际例子：

使用VB.NET建立Message对象
<%@ Assembly Name="System.Messaging.dll" %>
<script runat="server" language="VB">
Dim myDir As System.Messaging.Message = New System.Messaging.Message()
</script>

使用C#建立Message对象
<%@ Assembly Name="System.Messaging.dll" %>
<script runat="server" language="C#">
System.Messaging.Message myDir = new System.Messaging.Message();
</script>

指令@Assembly表示将一个集合引用到当前的页面，从而使得所有在集合当中定义的类、界面、结构可以在当前页面自由的被使用。在我们上面给出的例子当中，我们绑定了System.Messaging.dll这个集合。在这个集合当中包含了System.Messaging这个名称空间，System.Messaging名称空间提供了存取.NET架构消息的功能。我们建立了Message类的一个实例，从而可以利用它存取消息队列当中的消息了。如果我们需要在一个代码绑定的文件中建立Message类，需要这样做：

使用VB.NET在代码绑定文件中建立Message对象
Public Class myPage
Inherits System.Web.UI.Page
Dim myDir As System.Messaging.Message = New System.Messaging.Message()
End Class

使用C#在代码绑定文件中建立Message对象
public class myPage : System.Web.UI.Page {
System.Messaging.Message myDir = new System.Messaging.Message();
}

需要注意的是，如果我们想要编译这个类，我们需要在编译的时候通知编译器我们需要引用System.Messaging.dll以及System.Web.dll这两个文件。假设我们将上面的类保存成为一个文件（mypage.vb或者mypage.cs），之后我们需要这样来编译它：
编译代码绑定的类

vbc mypage.vb /r:System.Messaging.dll /r:System.Web.dll
csc mypage.cs /r:System.Messaging.dll /r:System.Web.dll

传递给编译器的参数“/r:System.Messaging.dll”和“/r:System.Web.dll”同一个在Web Form上使用的指令@Assembly起到的作用是相同的。

什么是集合？

一个集合是一组具有相似功能的逻辑单元的组合。他是基础的，可以自描述的配置单元，具有版本控制，可重用，许可安全控制的属性。它包含那些用来表现所有指定版本需求，安全标示符和其他信息的集合名单。

引入名称空间

我们已经注意到了，无论什么时候我们引用Message对象，我们都需要提供完整的名称空间路径（也叫做完全限定的类名称）。不难想象，时间长之后，这将会带来令人厌烦和不必要的臃肿代码。幸运的是，我们可以在一个页面定义一个名称空间的路径，从而可以节约一些无谓的敲键盘的时间。

使用VB.NET引入一个集合
<%@ Assembly Name="System.Messaging.dll" %>
<%@ Import Namespace="System.Messaging" %>
<script runat="server" language="VB">
Dim myDir As Message = New Message()
</script>

使用C#引入一个集合
<%@ Assembly Name="System.Messaging.dll" %>
<%@ Import Namespace="System.Messaging" %>
<script runat="server" language="C#">
Message myDir = new Message();
</script>

在我们的代码绑定类中则应当这样书写：

使用VB.NET在代码绑定文件中引入一个集合
Imports System.Web.UI
Imports System.Messaging
Public Class myPage
Inherits Page
Dim myDir As Message = New Message()
End Class

使用C#在代码绑定文件中引入一个集合
using System.Web.UI;
using System.Messaging;
public class myPage : Page {
Message myDir = new Message();
}

通过指令@Import（同样可以通过Imports或者using语句），我们可以指定一个名称空间的路径。这样，我们在引用一个类的时候，就不必使用完全限定的名称空间路径了。注意：如果在System.Web.UI和System.Messaging这两个名称空间中都有Message这个类的话，我们就必须使用完全限定的类名称了。

清楚的知道引入的名称空间能做什么和不能做什么是非常重要的。它不仅仅是节约了程序员的敲击键盘的时间，更重要的是带来了程序代码的良好的可读性。需要明白的是，真正正式将名称空间连入到页面的指令是：@Assembly或者使用参数/r进行编译。

通过配置文件自动控制将集合连入到一个web form并不是只有使用@Assembly指令一个方式，集合也可以在一个application当中自动的被引入某个页面。这样的集合不需要指令@Assembly。我们可以在配置文件config.web中使用<assemblies>来自动引入集合。

自动的在配置文件当中引入集合
<configuration>
<compilation>
<assemblies>
<add assembly="System.Messaging"/>
<add assembly="*"/>
</assemblies>
</compilation>
</configuration>

这个星号“*”通知ASP.NET自动引入在“应用程序的私有集合缓冲区”中的每一个集合。通过<add>元素，你可以引入任何的名称空间在application作用域之内。

什么是应用程序的私有集合缓冲区？

.NET的文档中是这样定义应用程序的私有集合缓冲区的：应用程序的私有集合缓冲区被看作是位于应用程序下的子目录\bin以及.NET构架的安装目录。然而通过我的测试，只有\bin目录才被当作应用程序的私有集合缓冲区，也就是说只有这个目录才是星号“*”的作用域。

注意：在<add>元素中的星号“*”仅仅自动连入那些位于应用程序子目录\bin中的集合！
通过查阅.NET架构安装的默认配置文件：config.web。我们可以知道，他自动的引入了如下的集合：

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
*

你可以自己看看默认的config.web文件，也好确认一下。下面的名称空间也是自动引入的：

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