The Microsoft .NET Framework is a rich and powerful runtime environment for creating and deploying Web-based applications. But, it's rife with gotchas and pitfalls for the inexperienced programmer -- and some of these can result in subtle and irritating bugs.

This article dicusses one common issue when working with .NET, especially onerous to transitioning C++ and Visual Basic 6 COM programmers: the inability to determine the exact lifetime of a .NET object. In C++ and VB6, you know the exact moment an object is created and the exact moment of its destruction. This isn't true of .NET objects.

The .NET garbage collector is responsible for disposing of objects and releasing the memory allocated to them. It does this, approximately, "when it feels like it." In short, you have little control over the destruction of objects.

You can force the garbage collector to dispose of all objects in memory by calling the System.GC.Collect() method, but this is inefficient. It's better to work with the Framework, as designed, and let the garbage collector do what it was designed to do.

Thus, if you create a class that creates and manages valuable resources -- such as a database connection or a data adapter -- you should implement a Dispose() method for your class. Further, you should ensure that you explicitly call this method when you finish using an instance of that class. This is important because even though .NET manages garbage collection for you, it does so non-deterministically, and therefore you can't assume it will free valuable resources in a timely manner.

This example shows a sub class declaration that manages a database connection and implements a Dispose() method:

Public Class MyClass
  Private objDBConn As SqlConnection

  Public Sub New()
    objDBConn = New SqlConnection()
  End Sub

  Public Overridable Sub Dispose()
    If (objDBConn.State <> ConnectionState.Closed) Then
        ObjDBConn.Close()
    End If
  End Sub

End Class

Because MyClass manages a valuable resource -- a database connection -- you must call Dispose() whenever you're done using an instance of it. Your explicit call to Dispose() will immediately free the valuable resources, and the garbage collector can throw away what's left of your class at its leisure. In general, you should implement a Dispose() method for any of your classes that instantiate instances of other classes that implement Dispose() methods (e.g., SqlConnection, SqlDataAdapter). The key here is that you, not the garbage collector, must control the use of expensive, limited resources. Certain resources, such as database connections, are of limited availability. Freeing them explicitly so other processes can use them is better for performance than letting the garbage collector free them when it feels like it:

Public Sub UseClass()

  Dim objMyClass As MyClass
  objMyClass = New MyClass()

  Try

    objMyClass.DoSomething1()
    objMyClass.DoSomething2()

 'Catch blocks removed for clarity

  Finally

    objMyClass.Dispose()

  End Try

End Sub

Note the placement of the call to Dispose(). It's in the Finally block of the Try statement. That means it will always be called, whether the code in the Try succeeds or fails. This is crucial because it guarantees resource release, and it demonstrates the optimum placement of the call to Dispose().

This issue of unpredictable object lifetimes can cause havoc in ASP.NET applications. When an ASPX page is viewed, the ASP.NET worker process creates an instance of a Page class, or a descendant of Page. If you use -- and you should -- code-behind for all your Web form work, there's no way to intercept the "completion" of the form, because there's no way to tell when the garbage collector will dispose of the form. Although it may be tempting to declare a SqlConnection as a member of your Web form for use by all the form's methods and events, this is bad practice because you don't have any opportunity to Close() the connection at the end of the page display.

Instead, it's best to write each event handler and overridden method of a Web form as if it were the only event handler in the entire object, like this:

Public Class MyForm
  Inherits System.Web.UI.Page

  Protected RadioButtonList1 As _
     System.Web.UI.WebControls.RadioButtonList

  Public Sub Page_Load()

      Dim objConn As SqlConnection()

      'Do some database work

      objConn.Close()

  End Sub

  Public Sub RadioButtonList1_SelectedIndexChange( _
     ByVal sender As System.Object, _
     ByVal e As System.EventArgs)

      Dim objConn As SqlConnection()

      'Do some database work

       objConn.Close()

    End Sub

End Class

In the example above, the code contains two handlers: Page_Load() and RadioButtonList1_SelectedIndexChange(). Note that both of these handlers open and close their own connection. They don't share a connection opened within the MyForm class. This may seen counterintuitive, but it helps your code scale better because it decreases the amount of time your code holds a connection. This, in turn, lets the CLR use its connection pool more efficiently.

You should understand that the CLR has a radically different approach to how resources are used and released. In other programming environments, you were motivated to share connections or other resources and pass them around. When the last reference to an object was removed, that object's resources were immediately released -- that is, you knew when things were going to happen. But the CLR's non-deterministic garbage collector changes things. You can't assume resources will be immediately released when objects go out of scope or are destroyed. You've got to do the work of releasing expensive resources yourself.

This tip is an excerpt from G. Allan Alderman and Bryan E. Slatner's article, originally published in the 2005 Week 7 issue of VB.NET ADVISOR Magazine. Subscribers can read the full article, which discusses two other .NET gotchas, at http://My.Advisor.com/doc/16096.