Many ASP developers have used COM objects of one sort or another in writing their code. Either custom objects were made to create a middle layer between ASP and other data, or the ADO COM objects were used directly. Even though the .NET architecture does not replace COM, you must be aware of some issues when you use legacy COM objects that were designed for ASP.
The first thing to be aware of is that ASP.NET code does not directly call COM objects. COM objects are called through what is called the COM Interop layer. This layer manages the conversion of data types between .NET and COM.
Because all calls to a COM object go through an extra layer of code, calling COM objects has a negative performance impact compared to calling native .NET objects. To offset this, COM objects can be early bound in ASP.NET. This means that method calls no longer need to use the IDispatch interface; instead, references to methods and properties of the COM object are made at compile time. Although you can continue to use your COM objects in the late bound method as you did under ASP, switching to the early bound syntax increases performance. Generally, the extra performance provided by early binding more than offsets the extra cost of using the COM Interop layer.
Late bound syntax looks like this:
Dim Obj As Object Obj = Server.CreateObject("progid") Obj.MyMethodCall()
Early bound syntax looks like this:
Dim Obj As New MyObject Obj.MyMethodCall()
When using early bound syntax, you must add a COM reference to your Visual Studio .NET project to be able to use the COM object or create a .NET wrapper.
With the early bound syntax, you no longer need to call Server.CreateObject unless the object needs to access the ASP intrinsic objects.
Specifying the Option Strict keyword in your code forces you to declare all objects in an early bound manner and generate a compiler error any time you don't.
Following is a list of the steps necessary to implement an early bound COM object using Visual Basic .NET:
In ASP, the ASP engine automatically detects situations where Single Threaded Apartment (STA) components are used and locks the server down to a single thread if they are stored in the Session or Application objects. This could severely degrade the performance of the server when this is required. To increase performance, ASP.NET by default requires that all components used have the Multiple Threaded Apartment (MTA) model.
If your application uses STA components, you need to use the ASPCompat directive. This attribute is provided to allow backward compatibility. Care should be taken when using this attribute because it can negatively affect performance. STA components include, but are not limited to, all components created using Visual Basic 6.0 or earlier.
The ASPCompat directive is set inside a page directive like this:
<%@ Page ASPCompat="true" Language="VB" %>
If your objects are MTA objects marked as Both or Free , you do not need to use the ASPCompat directive. Table 27.1 summarizes when to use the ASPCompat directive.
Table 27.1. ASPCOMPAT Use for COM Objects
Either early bound or late bound syntax can be used in all cases, though early bound syntax is preferred.
ASP Intrinsic Objects
There are someadditional issues if your COM object uses the OnStartPage and OnEndPage methods to gain access to the ASP intrinsic objects. If your COM object uses these methods, you need to set the ASPCompat directive to True, as shown in the preceding section. You also must create your object with a call to Server.CreateObject . The following is an example of how to create your object using early bound syntax:
Dim Obj as MyObj Obj = Server.CreateObject(MyObj) Obj.MyMethod()
Note that for early binding, you must pass the object type to Server.CreateObject rather than the program ID. You also will need to add a reference to your COM object in Visual Studio .NET. Late bound syntax is the same as for ASP.