| Recall that when you compile these objects in the .NET Framework, the objects must emit metadata describing themselves. The Common Language Runtime (CLR) uses this data to load the objects without any developer intervention. Simply place the objects in the /bin directory and you're off and running. However, older objects that weren't developed in the .NET Framework (often known as Component Object Model, or COM, objects) did not provide that capability. There was no CLR to automatically manage and load these objects, and no metadata to tell the CLR about them. Developers had to register the components manually using REGSVR32.exe, which placed information into the Windows Registry (a location that contains information about all the applications and components installed on the machine). Note COM objects are called "older" because the technology used to create them is older than the .NET technology not because the objects themselves are older.
These COM objects were built in a non-.NET environment, so they're not managed by the CLR and are known as unmanaged code. Because of this, ASP.NET has a slightly harder time figuring out how to use these objects. For one thing, you cannot set COM objects' properties at design time. ASP.NET still supports using these objects with the CreateObject method of the HttpServerUtility class. This method takes a string that describes the object's location in the Registry, and uses that to set the object's properties. This string is known as the progId. The syntax is Server.CreateObject(progId) For example, in classic ASP pages, I/O operations were performed with the FileSystemObject from the Scripting library. This object provided some of the same functionality as the classes you learned about on Day 13, "Reading and Writing Files on the Web Server." To use this object in your pages, you would have to use the following code: dim objFSO as object objFSO = Server.CreateObject("Scripting.FileSystemObject") For example, Listing 15.10 demonstrates how to display the path of a given file. Listing 15.10 Using COM Objects 1: <%@ Page Language="VB" %> 2: 3: <script runat="server"> 4: sub Page_Load(Sender as Object, e as EventArgs) 5: dim objFSO, objFile 6: objFSO = Server.CreateObject _ 7: ("Scripting.FileSystemObject") 8: objFile = objFSO.GetFile _ 9: (Server.MapPath("../day13/log.txt")) 10: 11: lblMessage.Text = objFile.Path 12: end sub 13: </script> 14: 15: <html><body> 16: <asp:Label runat="server"/> 17: </body></html>  | This creates a Scripting.FileSystemObject and Scripting.File object on lines 6 and 8. You can then use these objects to perform some I/O functionality, such as displaying the full pathname of the file. Figure 15.7 shows the output of this listing. |
Figure 15.7. ASP.NET supports using older, unmanaged COM objects.
However, using FileSystemObject isn't very interesting because you already have better objects in the .NET Framework, such as TextReaders and TextWriters, which are fully object-oriented. The real benefit of .NET's capability to use COM objects is for developers who have already created many custom COM objects. Many businesses that have Web sites often use several COM objects to do the same types of operations that you used business objects to do earlier today. Having to rewrite all those COM objects would be a tremendous hassle. Many other applications also expose their functionality through COM objects. For instance, you can create and manipulate Microsoft Word documents in your ASP.NET pages through the COM methods that Word exposes. All of Word's COM objects are unmanaged code, but that doesn't stop you from using them in the .NET Framework.  | There's a drawback to using COM objects, however. Because there's no metadata associated with these objects, ASP.NET has a hard time determining what kind of data an object takes and returns, and often it has to convert data types. This process is known as marshalling. It impairs performance due to increased processing overhead, so you should avoid it if possible. |
Luckily, the .NET Framework comes with a program that can convert unmanaged COM objects into managed .NET objects. This program, known as the Type Library Importer, examines the COM object and creates the appropriate metadata so that you can use it in your ASP.NET applications. This application is executed with the tlbimp.exe file. For example, let's assume that you want to use the FileSystemObject in your ASP.NET pages, without the costs of marshalling. This object is stored in the scrrun.dll file, usually located in the c:\winnt\system32 directory. Open up a command prompt and navigate to that directory. Type the following command into the window: tlbimp scrrun.dll /out:scrrun_net.dll This creates a new file called scrrun_net.dll from the scrrun.dll COM file, with the appropriate metadata. You should see something similar to the output in Figure 15.8. Figure 15.8. tlbimp.exe imports older COM objects into the .NET Framework.
Copy this new file into your assembly cache (c:\inetpub\wwwroot\bin). Now you can modify the previous listing to use the new, managed FileSystemObject. Listing 15.11 shows an example of using the new FileSystemObject. Listing 15.11 Using Imported COM Objects 1: <%@ Page Language="VB" %> 2: 3: <script runat="server"> 4: sub Page_Load(Sender as Object, e as EventArgs) 5: dim objFSO as new Scrrun_net.FileSystemObject 6: dim objFile as Scrrun_net.File 7: objFile = objFSO.GetFile(Server.MapPath _ 8: ("../day12/log.txt")) 9: 10: lblMessage.Text = objFile.Path 11: end sub 12: </script> 13: 14: <html><body> 15: <asp:Label runat="server"/> 16: </body></html> Now you're back to the familiar way of instantiating objects. Notice that the FileSystemObject now belongs to the Scrrun_net namespace, which is exactly the new filename you've created. This provides a large performance boost over the previous listing, and it allows you to use these older COM objects just as you would use any .NET object. Note The .NET Framework doesn't actually convert the COM objects into .NET objects. Instead, it provides a wrapper that emits the necessary metadata the existing object isn't changed. Thus, COM objects still lack the full support of the CLR.
| 
