ASP.NET

I l @ ve RuBoard

I don't talk about ASP.NET much in this book, mainly because other books are dedicated to this topic and I want to provide content that's hard to find anywhere else. However, this is a perfectly good place to highlight some of the performance issues you might run into with ASP.NET. Let's face it: Web applications are playing an increasingly important role throughout the enterprise. And tracking down some of the performance issues ”which are usually the fault of bad assumptions ”can be a real pain.

ASP.NET Session State

Session state is probably one of the most misused technologies in ASP. It's one of those things that provides great convenience but causes most of the scalability and performance problems associated with Web applications. The situation is no different in ASP.NET. Session state has its advantages, but it's important to understand its limitations so you can avoid expensive mistakes. Here are three key guidelines:

• If you don't need it, don't use it.

• Don't store COM components in session state.

• Don't store objects with handles to fixed resources (such as database connections and local files) in session state.

STA COM Interop in ASP.NET

I mentioned in Chapter 4 that you can use the AspCompat page directive to play nice with COM components. You should follow certain rules to ensure that you don't shoot yourself in the foot , especially when you're dealing with single-threaded apartment (STA) COM components. COM interop always introduces some performance hit to your Visual Basic .NET applications, but there are special considerations for ASP.NET.

Fun with Construction

You should know by now that if you want to do COM interop with STA COM components in ASP.NET, you must enable the AspCompat page directive. But that doesn't tell the whole story. In fact, there's a really big catch. Even though the AspCompat directive ensures that your ASP.NET page executes on an STA thread, it does not ensure that it is constructed on an STA thread. This causes a huge problem when you instantiate COM objects in the constructor (either implicitly or explicitly) ”it essentially creates a COM object on a multithreaded apartment (MTA) thread, not a STA thread. So the following is a really bad idea:

 ImportsMyLibrary PublicClassWebForm1 InheritsSystem.Web.Page DimclsAsClass1 Dimcls1AsNewClass1()'Implicitconstructorcall PublicSubNew() MyBase.New() cls=NewClass1()'Explictconstructorcall EndSub EndClass 

If you want to create a COM object, you should do so in the Page_Load event instead of the constructor. The Page_Load event is called after the page constructor and before the Page_Render event. If AspCompat is enabled, the Page_Load event is guaranteed to be executed on a STA thread. So you can consider the Page_Load event as a kind of proxy constructor. The previous example should look like the following instead:

 ImportsMyLibrary PublicClassWebForm1 InheritsSystem.Web.Page DimclsAsClass1 Dimcls1AsClass1 PublicSubNew() MyBase.New() EndSub PrivateSubPage_Load(ByValsenderAsSystem.Object,_ ByValeAsSystem.EventArgs)HandlesMyBase.Load 'ThisisthecorrectwaytohandlecreatingtheCOMobjects cls=NewClass1() cls1=NewClass1() EndSub EndClass 

But, yet again, this doesn't tell the whole story. Creating ASP.NET pages in this way, using code-behind, makes it easy to control how your objects are created. But this is not the only way you can create pages. In fact, you don't have to use the code-behind model at all. Take a look at the following example, which is a self-contained ASPX page:

 <@ImportNamespace="MyLibrary"> <SCRIPTLANGUAGE=VBRUNAT=SERVER> 'Thisisimplicitlyinitializedduringconstruction Dimcls1AsNewClass1() </SCRIPT> <% 'ThisisinitializedinthePage_Rendermethod Dimcls2AsNewClass1() %> 

You can see in the preceding example how easy it is to trip up and accidentally create a COM object in the page's constructor. You can still get around this using the Page_Load method:

 <@ImportNamespace="MyLibrary"> <SCRIPTLANGUAGE=VBRUNAT=SERVER> Dimcls1AsClass1 PrivateSubPage_Load(ByValsenderAsSystem.Object,_ ByValeAsSystem.EventArgs)HandlesMyBase.Load 'ThisisthecorrectwaytohandlecreatingtheCOMobject cls1=NewClass1() EndSub </SCRIPT> <% 'ThisisinitializedinthePage_Rendermethod Dimcls2AsNewClass1() %> 

This all has to do with how the ASP.NET pages are built and then compiled. As you can see, it is possible to create a COM object in the constructor in three different ways ”all of them bad.

COM, Session State, and the Application Object

What can I say here? Just don't do it. Don't use COM objects with session state or the Application object. COM does not mix with either. It's the surest way to toast your Web application's performance.

I l @ ve RuBoard