asp.net
Using Parentheses with Method Calls
In ASP, you could freely call methods on objects without using parentheses, as shown below:
Sub WriteData() Response.Write "This is data"End SubWriteData
In ASP .NET, you must use parentheses with all of your calls, even for methods that do not take any parameters. Writing your code, as in the example below, allows it to function correctly in both ASP and ASP .NET.
Sub WriteData() Response.Write("This is data")End SubCall WriteData()ByVal Is Now the Default
In Visual Basic, all parameter arguments were, by default, passed by reference or ByRef. In Visual Basic .NET, this has changed so that all arguments are now passed by value or ByVal by default. If you still wish to have "ByRef" behavior, you must explicitly use the ByRef keyword in front of your parameters as follows:
Sub MyByRefSub (ByRef Value) Value = 53;End Sub
This is an area where you really need to be careful. When you are moving your code over to ASP .NET, I suggest double and triple checking each parameter used in your method calls to ensure that this change is what you really want. I suspect you will need to change some of them.
No More Default Properties
The concept of default properties no longer exists in Visual Basic .NET. What this means is that if you have ASP code that relies on a default property that was provided by one of your objects, you will need to change this to explicitly reference the desired property, as shown in the following code:
'ASP Syntax (Implicit retrieval of Column Value property)Set Conn = Server.CreateObject("ADODB.Connection")Conn.Open("TestDB")Set RS = Conn.Execute("Select * from Products")Response.Write RS("Name")'ASP.NET Syntax (Explicit retrieval of Column Value property)Conn = Server.CreateObject("ADODB.Connection")Conn.Open("TestDB")RS = Conn.Execute("Select * from Products")Response.Write (RS("Name").Value)Changes in Data Types
In Visual Basic .NET, Integer values are now 32 bits and Long types have become 64 bits.
Problems may arise when invoking methods on COM objects from ASP .NET or calling Microsoft® Win32® API calls inside your custom Visual Basic components. Pay special attention to the actual data types required to ensure you are passing in or casting your values correctly.
Structured Exception Handling
Although the familiar On Error Resume Next and On Error Goto error handling techniques are still allowed in Visual Basic .NET, they are not the best way to do things anymore. Visual Basic now has full-blown structured exception handing using the Try, Catch, and Finally keywords. If possible, you should move to this new model for error handling as it allows for a more powerful and consistent mechanism in dealing with your application errors.
COM-Related Changes
With the introduction of the .NET Framework and ASP .NET, COM really has not been changed at all. This does not mean, however, that you do not need to worry about COM objects and how they behave when you are using them from ASP .NET. There are a couple of fundamental things you need to be aware of.
Threading Model Changes
The ASP .NET threading model is the Multiple Threaded Apartment (MTA). What this means is that components that you are using that were created for the Single Threaded Apartment (STA) will no longer perform or function reliably without taking some extra precautions in ASP .NET. This includes, but is not limited to, all COM components that have been created using Visual Basic 6.0 and earlier versions.
ASPCOMPAT Attribute
You will be glad to hear that you can still use these STA components without having to change any code. What you need to do is include the compatibility attribute aspcompat=true in a <%Page> tag on the ASP .NET page. For example, <%Page aspcompat=true Language=VB%>. Using this attribute will force your page to execute in STA mode, thus ensuring your component will continue to function correctly. If you attempt to use an STA component without specifying this tag, the run time will throw an exception.
Setting this attribute to true will also allow your page to call COM+ 1.0 components that require access to the unmanaged ASP built-in objects. These are accessible via the ObjectContext object.
If you set this tag to true, your performance will degrade slightly. I suggest doing this only if you absolutely need to.
Early Binding Versus Late Binding
In ASP, all calls to COM objects occur through the IDispatch interface. This is known as "late binding" because calls to the actual objects are handled indirectly via IDispatch at run time. In ASP .NET, you can continue to invoke your components in this fashion if you like.
Dim Obj As ObjectObj = Server.CreateObject("ProgID")Obj.MyMethodCallThis works but it is not the preferred manner to access your components. With ASP .NET, you can now take advantage of early binding and create your objects directly as follows:
Dim Obj As New MyObjectMyObject.MyMethodCall()
Early binding allows you to interact with your components in a type-safe manner. In order to take advantage of early binding with your COM components, you need to add a reference in your project in much the same way that you add a COM reference to a Visual Basic 6.0 project. Assuming that you are using Visual Studio .NET, a managed proxy object is created behind the scenes, on top of your COM component, giving you the impression you are dealing directly with your COM component as a .NET component.
At this point you may wonder about performance. There is definitely some overhead involved when using COM interoperability as you now have an extra layer introduced because of the proxy object. In most cases, however, this will not be a factor because the amount of actual CPU instructions for the interoperation to occur is still substantially less than that required by your indirect IDispatch calls. You will be gaining more than you will lose. The ideal situation, of course, is to use newly created, managed objects, but we know that this will not always be possible immediately because of our investments in COM components over the years.
OnStartPage and OnEndPage Methods
One area that needs some additional consideration involves the use of the legacy OnStartPage and OnEndPage methods. If you rely on these methods to access ASP intrinsic objects, you will need to use the ASPCOMPAT directive and use Server.CreateObject to create your component in an early-bound fashion, as shown below:
Dim Obj As MyObjObj = Server.CreateObject(MyObj)Obj.MyMethodCall()
Notice that instead of using the "ProgID," we have used the actual type in an early-bound manner. In order for this to work, you will need to add a reference to your COM component in your Visual Studio project so that the early-bound wrapper class is created for you. This should be the only case where you must continue to use Server.CreateObject.
COM Summary
Table 2 is a summary of what you need to do to continue to use your COM components as efficiently as possible.
Table 2. ASP .NET Settings for Legacy COM Objects
COM Component Type/MethodASP .NET Setting/ProceduresCustom STA (Visual Basic Components or other components marked as "Apartment")Use ASPCOMPAT, use early bindingCustom MTA (ATL or custom COM components marked as "Both" or "Free")Do not use ASPCOMPAT, use early bindingIntrinsic Objects (accessed via ObjectContext)Use ASPCOMPAT, use early bindingOnStartPage, OnEndPageUse ASPCOMPAT, use Server.CreateObject(Type)
These same settings apply whether or not your components are deployed in COM+.
Application Configuration Changes
In ASP, all Web application configuration information is stored in the system registry and the IIS Metabase. This makes it quite difficult to view or modify settings because often the correct administration tools are not even installed on your server. ASP .NET introduces a whole new configuration model based on simple, human readable XML files. Each ASP .NET application has its own Web.Config file that lives in its main application directory. It is here that you control the custom configuration, behavior, and security of your Web application.
If you are like I was, you will be tempted to go to the Internet Services Manager snap-in to inspect and change the settings for your ASP .NET application. Understand, however, that we now have two totally separate configuration models. With the exception of some security settings, for the most part all other settings made using the IIS administration tool are ignored by ASP .NET applications. You need to place your configuration settings in the Web.Config file.
Application configuration with .NET is an article in itself and I will not detail it here. Table 3 shows some of the more interesting configuration sections you can set in your file. Keep in mind that there are many more.
Table 3. Sample Web.Config Settings
SettingDescription
<appSettings>Configures custom application settings.
<authentication>Configures ASP .NET authentication support.
<pages>Identifies page-specific configuration settings.
<processModel>Configures the ASP .NET process model settings on IIS systems.
<sessionState>Specifies session state options.
There are classes available in the .NET Base Class Libraries that simplify programmatic access to these settings.
State Management
If your application uses the Session or Application intrinsic object to store state information, you can continue to use these in ASP .NET without any problems. As an added benefit, you now have a couple of more options for your state storage location.
State Management Options
In ASP .NET, you have additional options for your state storage model that will finally allow you to go beyond a single Web server and support state management across a Web farm.
You configure your state management options in the <sessionState> section of your web.config file as follows:
<sessionState mode="Inproc" stateConnectionString="tcpip=127.0.0.1:42424" sqlConnectionString="data source=127.0.0.1;user id=sa;password=" cookieless="false" timeout="20"/>
The mode attribute specifies where you would like to store your state information. Your options are Inproc, StateServer, SqlServer, or Off.
Table 4. Session State Storage Information
OptionDescriptionInprocSession state is stored locally on this server (ASP style).StateServerSession state is stored in a state service process located remotely or potentially locally.SqlServerSession state is stored in a SQL Server database.OffSession state is disabled.
StateConnectionString and sqlConnectionString obviously come into factor if you use one of these other options. You can only use one storage option per application.
Storing COM Components
One thing to keep in mind is that if you rely on storing references to your legacy COM components in the Session or Application object, you cannot use the new state storage mechanisms (StateServer or SqlServer) within your application. You will need to use Inproc. This is due, in part, for the need of an object to be self-serializable in .NET terms, something that COM components obviously cannot do. New, managed components you create, on the other hand, can do this relatively easily and thus can use the new state storage models.
Performance
As far as performance goes, nothing comes for free, of course. One can safely assume that in most cases, Inproc will continue to be the best performer, followed by StateServer and then SqlServer. You should perform you own tests with your application to ensure the option you select will meet your performance goals.
Sharing State Between ASP and ASP .NET
Another important thing to consider is that although your application can contain both ASP and ASP .NET pages, you cannot share state variables stored in the intrinsic Session or Application objects. You either need to duplicate this information in both systems or come up with a custom solution until your application is fully migrated. The bottom line is that if you have made little use of the Session and Application objects, you should be in good shape. If, on the other hand, you use these objects extensively, you will need to proceed with caution and perhaps come up with a custom short-term solution to sharing your state.
Security-Related Changes
Security is another area that requires a great deal of focus. Here is a brief overview of the ASP .NET security system. Consult the ASP .NET security documentation for a more thorough investigation.
ASP .NET security is primarily driven from settings in the security sections of your web.config file. ASP .NET works in concert with IIS to provide a complete security model for your application. IIS security settings are some of the few application settings that will actually carry over and be applied to your ASP .NET application in a similar manner to that in ASP. There are, of course, many additional enhancements.
Authentication
For authentication, ASP .NET supports the different options shown in Table 5.
Table 5. ASP .NET Authentication Options
TypeDescriptionWindowsASP .NET uses Windows authentication.FormsCookie-based, custom login forms.PassportExternal Microsoft provided Passport Service.NoneNo authentication is performed.
These are the same options you have in ASP, with the exception of the new Passport authentication option. As an example, the following configuration section enables Windows-based authentication for an application:
<configuration> <system.web> <authentication mode="Windows"/> </system.web></configuration>
