· Separate code from HTML content as much as possible. · Use
Mixing Programming Languages
In ASP, you basically have two choices for your programming language: VBScript or Microsoft® JScript®. You are free to mix and match blocks of script in the same page at will.
In ASP.NET, you can use any Common Language Runtime-compliant language. C#, Visual Basic .NET, and JScript are the current languages provided by Microsoft. Note that I said Visual Basic .NET instead of VBScript. This is because VBScript does not exist in the .NET platform. It has been fully subsumed by Visual Basic .NET. Although you are free to pick any of these languages, it is important to note that you cannot mix languages on the same page as you could do in ASP. It is certainly possible to have Page1.aspx of your application contain C# code while Page2.aspx of the same application contains Visual Basic .NET code. You just cannot mix them together in a single page.
New Page Directives
In ASP you must place all directives on the first line of a page within the same delimiting block. For example: <%LANGUAGE="VBSCRIPT" CODEPAGE="932"%>
In ASP.NET, you are now required to place the Language directive with a Page directive, as follows: <%@Page Language="VB" CodePage="932"%><%@QutputCache Duration="60" VaryByParam="none" %>
Render Functions Are No Longer Valid
In ASP, developers figured out that they could do clever things by using what is termed a "Render Function." A Render Function is basically a subroutine that contains chunks of HTML embedded throughout its body. For example: <%Sub RenderMe()%>
This is HTML text being rendered.
<%End SubRenderMe%>Although you can do some cool things using these types of functions, this type of coding is no longer allowed in ASP.NET. This is probably for the better. I am sure you have seen functions that quickly become unreadable and unmanageable when you start to mix and match code and HTML like this. The simplest way to make this work in ASP.NET is to replace your HTML outputs with calls to Response.Write as follows: <% Call RenderMe()%>
Farewell to the Variant Data Type
We know it, we love it, we love to hate it. I am speaking of a VARIANT data type, of course. VARIANTs are not a part of .NET and thus are not supported in Visual Basic .NET. What this means is that all of your ASP variables are silently going to move from VARIANT types to Object types. Most variables used in your application can and should be changed to a corresponding primitive type depending on your needs. If your variable is really an object type in Visual Basic terms, simply explicitly declare it as an Object type in ASP.NET.
Visual Basic Date Type
One VARIANT type that warrants some special attention is the VT_DATE type, which manifests itself in Visual Basic as a Date type. In Visual Basic, a Date is stored in a Double format using four bytes. In Visual Basic .NET, Date uses the Common Language Runtime DateTime type, which has an eight byte integer representation.
Since everything is a VARIANT in ASP, your intended Date variables will compile and may continue to work depending on how they are used. It is possible, however, that you will run into some unexpected problems performing certain operations with the variable because the underlying type has been changed. Pay attention to areas where you may be passing the date value into COM objects as long integer values or performing certain casting operations on date types using CLng.
Option Explicit Is Now the Default
In ASP, the Option Explicit keywords were available but were not enforced as the default. In Visual Basic .NET, this has changed. Option Explicit is now the default so all variables need to be declared. It is good practice to be even more rigid than this and change your setting to Option Strict. Doing so forces you to declare all of your variables as a specific data type. While this may seem like extra work, it really is the way you should be doing things anyway. If you choose not to, your code will be less than optimal as all undeclared variables will become Object types. Most implicit conversions will still work, but you will probably be better off and safer if you explicitly declare all of your variables to the types you want them to be.
LET and SET Are No Longer Supported
Objects can be assigned to one another directly like this: MyObj1 = MyObj2. You no longer need to use the SET or LET statements. If you use these statements, they must be removed.
ASP: Set ObjMy=CreateObject(“”)
ASP.NET: objMy=CreateObject(“”)
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
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.
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
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 IDispatchat 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.MyMethodCall
This 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()
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.
ASP.NET Settings for Legacy COM Objects
COM Component Type/Method
ASP.NET Setting/Procedures
Custom STA (Visual Basic Components or other components marked as "Apartment")
Use ASPCOMPAT, use early binding
Custom MTA (ATL or custom COM components marked as "Both" or "Free")
Do not use ASPCOMPAT, use early binding
Intrinsic Objects (accessed via ObjectContext)
Use ASPCOMPAT, use early binding
OnStartPage, OnEndPage
Use ASPCOMPAT, use Server.CreateObject(Type)
These same settings apply whether or not your components are deployed in COM+.
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
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
Option
Description
Inproc
Session state is stored locally on this server (ASP style).
StateServer
Session state is stored in a state service process located remotely or potentially locally.
SqlServer
Session state is stored in a SQL Server database.
Off
Session 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.
ASP.NET Authentication Options
Type
Description
Windows
ASP.NET uses Windows authentication.
Forms
Cookie-based, custom login forms.
Passport
External Microsoft provided Passport Service.
None
No 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:
Authorization
Once your users have been authenticated, you can focus on authorizing what resources you would like them to have access to. The following sample shows access being granted to "jkieley" and "jstegman," while everyone else is denied access.
Impersonation
As a refresher, impersonation refers to the process whereby an object executes code under the identity of the entity on whose behalf it is performing. In ASP, impersonation will allow your code to run on the behalf of an authenticated user. Alternately, your users can run anonymously under a special identity. By default, ASP.NET does not do per-request impersonation. This is different from ASP. If you rely on this capability, you will need to enable this in your web.config file as follows:
Preparation for ASP.NET
Now that you have been exposed to most of the issues you are likely to encounter, you may be wondering what things you can do today to be better prepared for them when you finally move to ASP.NET. Quite a few things can be done that will make the process smoother. Many of these suggestions will be beneficial to your ASP code even if you do not move to ASP.NET until sometime in the future.
Use Option Explicit
This has always been a good idea but still not everyone uses it. By enforcing variables to be declared in ASP by using Option Explicit, you will at least have a handle of where everything is defined and how your variables are being used. Once you move to ASP.NET, I suggest using Option Strict. Option Explicit will be the default in Visual Basic .NET but by using the more enforcing Option Strict, you will ensure all of your variables are declared as the correct data type. Doing this definitely requires a bit of extra work but, in the long run, you will discover that is was well worth it.
Avoid Using Default Properties
As we discussed, default properties are no longer allowed. Accessing your properties explicitly isn't really that hard to do anyway. It will make your code more readable and also save you time in porting in the future.
Use Parentheses and the Call Keyword
Use parentheses and Call statements wherever possible, as detailed earlier in this article. In ASP.NET you will be forced to use parentheses. Using the Call statement today will help you add a bit of discipline that will better prepare you for the future.
Avoid Nested Include Files
This may be easier said than done but, if possible, you should avoid nesting your include files. To clarify what I mean by this, you should try to eliminate any areas where you have include files that include other include files. What tends to happen over time is that your code ends up relying on a global variable that is defined in an include file somewhere else, and you are getting access to it only because you have included another file that includes the one you really need.
When you migrate to ASP.NET, you will most likely be moving your global variables and routines into class libraries, in which case, it is much easier to do if you have a clear picture of where you are getting access to everything. You may end up having to move things around and change some routines' names that were duplicated in multiple files.
Organize Utility Functions into Single Files
One strategy used in the migration process is to migrate all of the utility functions and code contained in your server-side include files into Visual Basic or C# class libraries. This allows you to finally put all of the code where it belongs—in objects, as opposed to multiple-interpreted ASP files. By organizing your code ahead of time, you will be saving yourself time in the future. Ideally, you should be able to group your sub-routines together in logical files thus allowing you to easily create a set of VB or C# classes. These are the functions that probably should have been in COM objects in the first place.
If you have a bunch of global variables or constants mixed in server-side include files, consider placing all of them in a single file, as well. Once you move to ASP.NET, you can then easily create a class that will house your global or constant data. This will make for a much cleaner and more maintainable system.
Remove Code from Content as much as Possible
This is another thing that is easier said than done but, if at all possible, you should separate your code from HTML content. Clean up functions that mix code and script throughout a function body. Doing so puts you in a much better position to leverage code-behind as this is the ideal model under ASP.NET anyway.
Do Not Declare Functions Inside <% %> Blocks
This is not supported in ASP.NET. You should be declaring your functions inside