Asp.net| difference If You ' re have 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 for you ever had.
What has Changed Compared to ASP Classic?
If you ' ve developed Active Server Pages you'll 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 a instance of class "We use" CreateObject method of the Server object. In the above code the variable FSO is the declared and then assigned a reference to the FileSystemObject object that can Be found in the Scripting library. The to work it are necessary that 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 are want to use a 3rd-party component or one of your created yourself, you'll need to take care of installing and registe Ring it.
Let's now have a look at how the FileSystemObject object, if it existed, would being 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, 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 your 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 are referring to the FileSystemObject class, that can is found in the Scripting namespace. Note this such namespace doesn ' t exist in the. NET Framework and therefore the above code would not work. On the "other hand" we could create our own scripting namespace and define the FileSystemObject class in it.
What is a Namespace?
The previous section the word "namespace" has been used. By means of namespaces, can systematize classes into logically related. As a, you'll cluster classes that provide similar functionality or have a. For instance the System.IO namespace contains classes. are used to deal with input-output-like operations, reading ting or deleting files. Note that similar functionality and/or similar the context isn't a formal requirement. You are the organize your namespaces along any rules, even no rules.
Referring to. NET components
As already noted, the ASP.net example is there for didactical reasons--it ' t wouldn. 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 a Assembly to the current page, making all of the classes, interfaces and structures Defin Ed 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" 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 this if we wanted to compile the class, we would need to provide the compiler with the reference Ing.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 Compi Lation 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 O n a Web Form.
What is an Assembly?
An assembly forms a logical the unit of functionality. It is the fundamental, self-describing unit of deployment, version control, reuse, activation scoping, and security permis Sions. It contains the assembly manifest, which represents all the metadata needed to specify the version requirements Identity, and other information.
Importing namespaces
You'll have noticed, that's whenever we refer to the "Message object," We always need to provide the "Full namespace path" (an The other words fully qualify the class name). It isn ' t hard to imagine, while this could is cumbersome and unnecessarily 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 is rewritten as follows:
Importing a 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 a 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 as the the Imports or the using statements we can specify the namespace path to the Classes we use. Have done so we can later refer to the classes without fully the qualifing path. Note this if both the System.Web.UI and the System.Messaging namespace had a message class, we would have to qualify the C Lass name.
It is very important to be aware of what importing a namespace does and what it doesn ' t. Its only, albeit handy, the "is" to save the programmer some keystrokes and bestow the code with better readability. It alone isn't 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 isn't the only way to link assemblies to a Web form. Assemblies can be automatically linked to the pages within an application. Such assemblies does 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 a application ' s private assembly cache. By means of the <add> element you can link any namespace into 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 th E Microsoft. NET Framework Install folder. My tests, though, have proven this only the \ Bin sub-folder is considered to being the private cache--in the sense that For that folder would the asterisk wildcard work.
Important note:if You have skipped the box above, there are one thing worth knowing:the in the <add> asterisk NT would 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 in your system to confirm. 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 are happen to know this, please drop me a line.
