Introduction

If you are an ASP.NET developer like me, then I'm sure you've wondered about the new releases of Visual Studio and SQL Server and what their implications are for the projects you work on. The new releases prompted me to look at the existing applications that I oversee for my company and determine whether or not they should be upgraded. Instead of examining the individual projects first, I decided to look at VS2005 and SQL Server 2005 to see if they made it worth upgrading. If you haven't yet come to the conclusion that it's worth it, trust me – it is.

In this article, I provide some of my reasons for upgrading my company's facilities request web application to ASP.NET 2.0 and SQL Server 2005. This is the first of many (about ten) web applications that are currently in production within my company. I'll mention some of the issues I encountered during the upgrade, some of the cool new features I noticed in VS2005, ASP.NET 2.0, and SQL Server 2005, and a couple of instances where .NET 1.1 classes are being obsoleted. Finally, I discuss in detail two of the new .NET 2005 features that I was able to benefit from by upgrading this project: the new GridView control available in ASP.NET 2.0, which allows you to obtain paging and sorting of data without any explicit coding, and the in-built support to encrypt connection strings in configuration files.

System Requirements

There is no sample code associated with this article, but if you wish to carry out similar upgrades on your own projects, it's likely that you'll need the following:

• Windows 2000 Professional or Windows XP Professional
• .NET Framework version 1.0 or 1.1
• VS2003
• SQL Server 2000
• .NET Framework version 2.0 Beta 2
• VS2005 Beta 2
• SQL Server 2005 CTP April 2005

Some Benefits of Upgrading

I am a software engineer and database administrator for a large manufacturing company. I have a lot of input into the technologies that are used at the company, especially when it comes to web applications. However, I am also ultimately responsible for those applications and any impact those applications may have on my company. So if I recommend or push for a technology that is not mature or does not provide enough benefits, it reflects poorly on me.

So why would I want to upgrade an existing production application to ASP.NET 2.0 and SQL Server 2005? I first needed to determine if the upgrade should be done or if my company should just preserve the status quo. Of course, being a developer, I wanted to play with the latest technology. However, I still have that responsibility to my company, and therefore I could not just jump into developing web applications with VS2005 and SQL Server 2005 unless I could show the specific benefits of doing so. So I did some investigating, attended some seminars (thanks, Microsoft!), and sat down to review all of the information gathered and make some decisions.

Benefits of SQL Server 2005

Although there are many benefits to moving to SQL Server 2005, two key reasons stood out to me: DDL triggers and integrated source control .

• DDL triggers are triggers that can be fired when database changes are made, such as when a column is added to a table or a table is dropped. For me, this has inspired a vision where all databases will have these triggers that will audit all changes to the database structure, I will include them with the model database. This takes the task of keeping track of database changes out of the hands of the developer or even the DBA and makes the changes automatic.
• Integrated source control means that with SQL Server 2005 you can use a source control add-in such as Visual SourceSafe to allow checking in and checking out of code. This again will help with the administrative work done by developers by ensuring they are not harming the code base and ensuring that only one developer is changing a stored procedure at a time. But most important, this feature provides the ability to restore previous code if there is a problem. This feature will not be necessary within the production environment, but it will definitely come in handy during development and testing.

DDL triggers and integrated source control are not the sexiest, coolest toys or new features, but to my company they provide the most benefit. Both are features we have been waiting for. Some other cool features worth noting include the following:

• Full CLR integration will help with complex stored procedures, as they can now be handled with VB or C# within SQL Server instead of stored procedures being restricted to T-SQL. It also provides for autocompletion and parameter tipping for stored procedures.
• Better error handling within stored procedures.
• New SQL management objects expose the functionality of the SQL Server database. These can be used to automate repetitive and common administrative tasks.
• New security model for SQL Server Agent can be used to grant permissions to add, edit, or execute SQL Server Agent jobs.
• Multiple active result sets allow more than one request per connection. This could be used most often in a parent/child relationship.

The next step was to determine what impact changing to SQL Server 2005 would have on my company's developers. My first question was, have the tools changed since SQL Server 2000?

What I learned about SQL Server 2005 is that yes, there have been very significant changes made to the tools. First, Enterprise Manager, which we all know and love, is no more. Instead, there is the new SQL Server Management Studio , which looks nothing like the old Enterprise Manager. Figure 1 shows a snapshot of SQL Server Management Studio.

Figure 1. The new SQL Server Management Studio

You will notice there are a lot of changes to how the Studio looks as compared to Enterprise Manager. Also, Query Analyzer is no longer a separate tool that needs to be called from a menu. Instead, you can create a Database Engine Query within a window in the right pane. So there will be a learning curve when you attempt to start using SQL Server 2005 from an administrator or developer point of view. If I upgrade all of the database servers, and therefore all of the developer workstations, then the developers will need to be trained on how to use the new SQL Server Management Studio. That was a problem, but it wasn't enough of an obstacle to outweigh the benefits of upgrading.

Benefits of VS2005

After deciding I was going to move to SQL Server 2005, the decision to move to VS2005 had to be made. One line of reasoning is that both SQL Server 2005 and VS2005 require .NET Framework 2.0. So if you have to install .NET Framework 2.0 for SQL Server 2005, you might as well install VS2005 also. That was my first thought, but then of course the responsibility thing kicked in again and I had to justify it. While I was investigating SQL Server 2005, I also learned a great deal about VS2005 and ASP.NET 2.0. I must admit, with VS2005 and ASP.NET 2.0 there were no features that blew me away in the way that aspects of SQL Server 2005 did. However, there is still much that I am looking forward to in VS2005 and ASP.NET 2.0.

First-although it's not so much a feature to be used as an organizational change-the code-behind file is now just a code file. Within an ASP.NET application, all of the code not specifically for a page is moved to an app_code folder. Partial classes are now created when a web page is created. The idea behind a partial class is that the class definition is spread over more than one file, allowing multiple developers to work on the same class simultaneously, and at compilation time the partial definitions in each file will be brought together. ASP.NET 2.0 takes advantage of this by treating the .aspx page and what used to be the code-behind as partial class definitions. Also related to organizational change is the fact that web projects no longer exist as separate files; instead, all files within a directory are part of the website.

Another change that has been made is the lack of IIS dependency. Now IIS is not required on a development workstation. VS2005 comes with its own built-in web server that can be used to hit web pages only on the local host but can be used without IIS being installed. Other workstations cannot access the web pages, but this works great for development and testing if network administrators do not want to install IIS on the development workstations.

There are several specific changes for ASP.NET applications. The first is the new Master Pages object. You can create a master page that provides a layout for all pages within an application or a section of an application, and then apply that master page to all pages within the application or section. With this feature, you can place your logo and other important controls like a help link in the same place on every page without placing each item on every page manually. This is a great feature, and it's one of the reasons I want to move all web development in my company to VS2005. The second specific change to ASP.NET applications is the creation of themes. You can create themes that define how text and buttons will look by creating skins. These skins can be applied to controls, and they can be used for personalization and standardization. Finally, there are three new controls that I really like. The first, and most interesting to me, is the GridView . The GridView control has built-in functionality for paging through and sorting data. Later in this article I discuss using the GridView . The second is the SiteMap path control, which can be used for breadcrumbs on each page. The third is new and improved hover over javascript control. With this control, you do not need to develop your own or find a third-party control. Based on these features, mostly those related to ASP.NET 2.0, I decided it was a good idea to move our development to VS2005.

My Experience Upgrading the Application

In this section, I describe the application that I upgraded and discuss some of the issues I encountered during the upgrade.

Organizing the Upgrade

My final decision related to whether I should upgrade any existing projects or just start with new applications. I could keep around a SQL Server 2000 database server to keep all of our existing applications on and just create new applications with VS2005 and SQL Server 2005. I could upgrade the projects to VS2005 and keep the database at SQL Server 2000, but this would not allow me to take advantage of the new features that convinced me to move to SQL Server 2005 in the first place.

Finally, I put my plan down on paper. The plan was to first test the upgrade of one representative web application and database. Then later in the summer or this fall when SQL Server 2005 licenses become officially available, I plan to move the database servers to SQL Server 2005 and start developing with VS2005. The remainder of this article describes my experience with upgrading that first project and database, and I also illustrate what you can do with the GridView control and with connection string encryption.

The Existing Application

The existing application is a facilities request application that allows users to submit new requests for facilities assistance. A facilities request is basically a maintenance request. For example, a ticket may be entered for the facilities (maintenance) staff to change a burned-out light bulb. With this application, the users that are members of the facilities (maintenance) staff use a screen to view a list of the requests that have been submitted.

The existing application makes use of the DataGrid control, which allows paging but does not allow sorting by columns other than the default sorting. Paging roughly means allowing the user to only view a specified number of records on the screen (e.g., records 1 through 10) with a button to allow the user to go to the next "page." Figure 2 shows the screen that is used by the facilities group members to view the list of requests.

Figure 2. Existing DataGrid

Moving the Database to a New Server

Since I am going to use SQL Server 2005, I have made a choice to not upgrade the existing database server but instead to have another database server built with SQL Server 2005 on it. The main reason for this is safety. My company has five database servers in production use, and none of them can afford to be offline for any amount of time. So I decided to take the safe route and use a separate server and move the databases over one at a time after some testing on each. My plan was to first build this new SQL Server 2005 server and start testing existing databases on it, and then upgrade an existing desktop SQL Server 2000 to SQL Server 2005 to get an idea of the process for the upgrade. When SQL Server 2000 was first released, I found the upgrade from SQL Server 7 to SQL Server 2000 to be rather painless, so my guess was the upgrade from 2000 to 2005 would be smooth, too-but again, that responsibility thing keeps coming back.

The first step was to move the database from the existing SQL Server 2000 server to the new SQL Server 2005 database server. There are a couple options available to move servers, but my personal choice (for no other reason than preference) is to always use the detach and reattach options. To do this, first make sure there are no current connections to the database. Then right-click the database, choose All Tasks , and then select Detach Database . Click OK to perform the detach.

To see what current connections exist, expand the Management folder on the SQL Server 2000 database in Enterprise Manager. Choose Current Activity . This will show all of the current connections to the database server. Find any connections that exist for the database you plan to remove, right-click it, and choose Kill Process . This will remove the connection.

After detaching the database you should copy, the .mdf and .ldf files to the new server and right-click the Database folder within the Object Explorer window of the Microsoft SQL Server Management Studio, as shown in Figure 3.

Figure 3. Attaching a database to a new server, step 1

When the Attach Database window appears, click the Add button as shown in Figure 4.

Figure 4. Attaching a database to a new server, step 2

After you click the Add button, the Locate Database Files pop-up window appears. The file explorer will default to the Data folder within the installation location for the SQL Server instance. Choose the .mdf file that you want to attach and click OK as shown in Figure 5.

Figure 5. Selecting the .mdf file to attach

After you have selected the .mdf file, verify that the name is correct for the database you want to create and click OK .

You can verify that the database has been added by expanding the Database folder within the Object Explorer as shown in Figure 6.

Figure 6. Verifying that the database has been attached

Restoring Database User Logins

When you detach a database and reattach it on another server, the users that were part of the database probably will not have logins to the new database server. This would not be an issue if I had upgraded an existing SQL Server 2000 database server to SQL Server 2005; it is an issue only because I chose to create a new server with SQL Server 2005 on it. To determine if there are "orphan" users, execute the sp_change_users_login 'Report' statement within a Database Engine Query.

There are several ways to create a new Database Engine Query. The first is to click the button New Query that appears close to the File menu at the top left of the SQL Server Management Studio and select New Database Engine Query , as shown in Figure 7.

Figure 7. Using the New Query menu

Another option is to right-click the database name and choose New Query , as shown in Figure 8

Figure 8. Using the context menu to write a new query

The stored procedure sp_change_users_login has been around for a while in SQL Server. If in the database that you are moving, you have any users based on SQL Server authentication (as opposed to integrated Windows authentication), those users will need to be fixed. A typical result set from sp_change_users_login is shown in Figure 9. The report shows which users within the database do not have a database server login. These are the database users that must be added as server logins before they can be used.

Figure 9. Results of an sp_change_users_login query

When adding the new user to this server, I normally provide the same password as was provided on the previous SQL Server-that saves changing the password in the application. Do not attempt to grant specific database access to the new SQL Server login. Instead, execute the statement sp_change_users_login 'Auto_Fix',[login name] , where [login name] is the name of the login to correct. You will receive a message that the login has been corrected. Now the database is ready to be used. To verify this, open a new Database Engine Query window and connect as the database user that was just corrected

Upgrading the VS Project file

The next step is to upgrade the VS project file from 2003 to 2005. The procedure I followed was as follows. First, copy the directory with the web application folder to the location you want the updated application to reside. Next, open the solution file ( .sln ) from the web application folder. This will automatically open VS2005.

The Visual Studio Conversion Wizard screen appears, as shown in Figure 10. Click Next to start the wizard.

Figure 10. Starting the Visual Studio Conversion Wizard

The next screen that appears asks if you want to create a backup. I chose no, as shown in Figure 11, since I had another copy of the application on its existing production server as well on as a development machine.

Figure 11. Selecting whether to create a backup

After the backup question, click Next and then Finish on the next screen. The conversion will begin at that time. I found the process relatively painless. It generated some warnings that I worked through, after which I was able to change my connection string and test the application.

Project Structure Changes

After the project opens, if you open Solution Explorer you may see that the upgrade has modified the project structure. Details vary according to the project, but the following table indicates some new folders that you might typically see created.

New Folder	Purpose
App_Browsers	Can contain definition files that ASP.NET uses to identify individual browsers and determine capabilities.
App_Code	Contains the source code for components or classes to be compiled as part of the application. Code in this folder is compiled when a page is requested.
App_Data	Can store database files such as Access files, SQL Express data files, or XML files.
App_GlobalResource	Contains .resx files used to make an application global.
App_LocalResource	Contains .resx files used to implement localization.
App_Themes	Contains files that define the appearance to take advantage of the new themes within ASP.NET.
App_WebReference	Contains proxy classes, schemas, and other files dealing with web services.
Bin	This folder is the same as the previous one. It contains the assemblies (.dll files) for the project.

Within the project structure of the upgrade project is a file called ConversionReport.txt , which is the log for the conversion. If you look through the log for a typical ASP.NET project, you will see how some files have been removed and some directories have been either renamed or created. Also you'll probably notice the keyword Public has been changed to Partial for all of the classes that are Web Forms. This is so they work according to the so-called code-beside model that is used within VS2005.

Upgrade Warnings

You may also see a window at the bottom of the screen listing warnings that may cause a problem when you build and deploy the application. For example, I was not aware of the fact that in some places in the old VB .NET code I had not added the As clause to indicate the type when declaring some public properties. This is flagged in the upgraded code as a warning. If you click the warning, you see that without a type declaration (like as String ) the type Object is assumed-this, of course, will happen in .NET 2003 too, but it's quite useful during the upgrade to get the warnings of where you have done this. This problem is not enough to generate an error on building the application, but it could cause you problems with type conversions and may cause the code to use more memory. Also, if you are using a configuration file such as web.config and you were using the ConfigurationSettings class within the System.Configuration namespace to read configuration data, you will receive a warning because this class is to become obsolete, and you should therefore use the new ConfigurationManager class instead. This also applies to the System.Web.Mail.SmtpMail class, which will be replaced with System.Net.Mail . Although code will still work with the old classes, I decided to take these suggestions, and I changed all of usages of the System.Configuration namespace to use ConfigurationManager instead, and I changed my code using SmtpMail to System.Net.Mail .

When working through the warnings I did, by the way, notice a possible bug that you should be aware of. I started at 101 warnings, but this number did not initially decrease as I fixed them. Apparently, the warnings list cannot display more than 101 warnings.

To give you an idea of how the SmtpMail change looks, here's an example of my original code:

Private NewMessage As System.Web.Mail.MailMessage
Private NewMail As Mail.SmtpMail
NewMessage = New Mail.MailMessage
NewMessage.To = Trim(StrTo)
NewMessage.From = Trim(StrFrom)
If StrCC & "" > "" Then
      NewMessage.Cc = Trim(StrCC)
End If
NewMessage.Subject = Trim(StrSubject)
NewMessage.Body = Trim(StrBody)
NewMessage.BodyFormat = Mail.MailFormat.Html
NewMail.SmtpServer = StrSMTPServer
Try
     NewMail.Send(NewMessage)
Catch ex As Exception
     Throw ex
End Try

Because of the warnings, I changed this code as follows:

Private NewMessage As System.Net.Mail.MailMessage
Private NewMail As System.Net.Mail.SmtpClient
NewMessage = New System.Net.Mail.MailMessage
NewMessage = New System.Net.Mail.MailMessage(
   StrFrom, StrTo, StrSubject, StrBody)
NewMessage.IsBodyHtml = True
NewMail.Host = StrSMTPServer
Try
NewMail.Send(NewMessage)
Catch ex As Exception
      Throw ex
End Try

A Useful VS IDE Improvement: Tracking Changes

While working through the project upgrades in VS2005, I discovered one of the many new features of VS2005 that struck me as so useful I thought it worth a mention here. The editor has a built-in change tracking system. When you make a code change, before you save it, a yellow marker is placed on the left side of the screen to show you which line you changed. This is a very useful feature if you make a correction and you are unsure what change you made. This yellow marker is shown in ChangeTracking.gif.

Figure 12. Yellow markings to track changes

After you save the file, any yellow marking changes to green. Again, this shows you what you changed even after you saved the change. This green mark will remain in place until the file is closed. So even after you make a change and save it, you can always find the changes that you made if you need to reverse a change. If you change the file outside of the IDE while the file is also in the IDE, when you return to the IDE the whole strip down the left side will also be yellow and turn green when it's saved.

Some New ASP.NET Features

In this section I discuss the GridView and connection string encoding. These are just two of numerous new features in ASP.NET. I've elected to discuss them because they were benefits I particularly noticed when upgrading the facilities request application and they are likely to be useful in numerous web applications.

The GridView Control

My existing facilities request application, no doubt like numerous ASP.NET applications, used the DataGrid control to display data. ASP.NET 2.0 includes a new control called a GridView . This is similar to the DataGrid but includes at least one new feature: built-in sorting. The ASP.NET 1.1 DataGrid required custom code for sorting, so when I heard about the new GridView and its built-in sorting ability, I wanted to give it a try.

The first thing to do to work with the GridView is to set up the database connection and database source. I used the DataSource control and created a database connection within the VS2005 Database Explorer. In case you're not familiar with this process, I'll quickly work though it here, so I can demonstrate how to get a GridView working without your having to write any explicit code.

To create a database connection within Database Explorer, right-click the Data Connections label at the top of the Database Explorer. The Add Connection window will appear. Either choose or type in the name of the database server, choose the login to use, and then choose the database to connect to. From then on you can work though the usual wizard to set up the connection.

During the wizard, you can choose where to get the data from. You have two choices: either from a custom SQL statement or stored procedure, or from a table and columns. If you choose custom SQL statement or stored procedure, then the Define Custom Statements or Stored Procedure window will appear, as shown in Figure 13. Click the Stored Procedures option at the bottom of the window and select the stored procedure from the list. The user that was defined when you created the connection must have permission to use that stored procedure.

Figure 13. Choose the data source just created

The next step is to choose the GridView control from the Data section of the toolbox and drag it to the ASP.NET page. Open the properties page by right-clicking the control and choosing Properties . Change the data source property to point to the data source you just created.

After you choose the data source, the GridView will automatically be created with the columns that are in the data source. You can choose a style for the grid or customize the look and feel of the GridView .

You will notice that the header of each column is the column name or alias given in the SQL statement. You can change this by clicking the GridView , viewing the properties, and clicking the ellipsis next to the column's property. A window called Fields will appear. You can select each field from the Selected fields area and get the properties for that column.

Figure 14. The Fields Window

You can also add command buttons to the grid by scrolling to the bottom of the Available Fields area in the Fields window. Click the button you want and click the Add button. Then you can chose that button (in my case, Select ) in the Selected Fields section of the Fields window and see the properties within the Properties section.

Figure 15. Select button

To enable sorting, all you need to do is find the AllowSorting property of the GridView control and choose True . The column heading of each column will be considered an active element and will be displayed based on the style or theme selected.

Now it's time to test out the new GridView . Begin by building the website and then navigating to the URL or choosing Start from the Debug menu. Click any of the columns, and that column will be sorted. All of that without any code!

Now to test to see what happens within paging and sorting. To do this, find the AllowPaging property of the GridView and change it to True . The default PageSize property is 10. This is the number of rows that will be on each page. After doing that, build the website, and either navigate to the URL or choose Start from the Debug menu. You should be able to sort by a column and then page from one page to the next within the GridView and the data will continue to be sorted.

Connection String Encryption

Another nice feature built into ASP.NET 2.0 is the ability to encrypt sections on the configuration file ( web.config ). This is a nice feature because the best practice has been to place your application settings, which included connection strings, in the web.config file. This file is just a plain XML file. The configuration file is easy to use and can be changed without rebuilding the application. The problem, of course, is that the web.config file is an XML file that can easily be read, especially if security is not set up correctly on the web server to limit access to the folder. Any ASP.NET developer knows the name web.config and could get to any website's file.

Taking advantage of this feature is very easy. Your web.config file already has a section called connectionStrings if you selected that you wanted save the connection string when creating the connection-this is not a new feature in VS2005 (it existed in VS2003). To encrypt the connectionStrings section, run the following command from the VS .NET command prompt:

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50215>
   aspnet_regiis -pe "connectionStrings" -app "/[applicationname]"
   -prov "RSAProtectedConfigurationProvider"

Replace [applicationname] with the name of the virtual directory your application is in. After you enter the previous command at the command window and press Enter, the encryption will begin. If there are no problems, you will see text that says Succeeded! That is all that is necessary to encrypt the connection strings portion of the web.config file.

Consider the following web.config file:

<protectedData>
  <protectedDataSections>
   <add name="connectionStrings" 
      provider="RSAProtectedConfigurationProvider"
    inheritedByChildren="false" />
  </protectedDataSections>
 </protectedData>
 <connectionStrings>
  <EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element"
   xmlns="http://www.w3.org/2001/04/xmlenc#">
   <EncryptionMethod 
      Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" />
   <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
    <EncryptedKey Recipient="" xmlns="http://www.w3.org/2001/04/xmlenc#">
    <EncryptionMethod 
        Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" />
     <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
      <KeyName>Rsa Key</KeyName>
     </KeyInfo>
     <CipherData>
      <CipherValue>qdjddQfgfe9L2o/DqI1JLO1OsLE+PleF9+hLgh18v/doZW2+eNYYV8vVYd/ewxc
3nDcqvfcMI4zrxq79LdEZETxc1D74cwtxYZOkXgytXzGGpY8658ZgAEQQxqS4XvX6IDKHK+Oyh53
xvlvovzUWGag6BtNmLXQr5b7kiF1osfw=</CipherValue>
     </CipherData>
    </EncryptedKey>
   </KeyInfo>
   <CipherData>
    <CipherValue>SQb9McY2VMXDADLrczEPiLD5AiJyqMDZUwrHgbrYEvdAUKHpAnKrica7ADQ5sYB
8mnrtN6lBML1iprTKIKUW+BcOpH/YZiUYsG6A08ieXQW/5ZpWGlN3DIL73XgVavBpr1s+I9+jQva
QR+34NkxvY9Y5KdtlCWq06IKAUx8u/wUdFBgyozL6DUD9tbiZI5ug9jUdPuN1vk7EywkjAhLQm+K
x9PpfHV7BFXcpTK9J9/3MRkP6nudH5OayanokB8zoAlK8PmNQM60+tlNAmupXHNA/x20DmBD0bxE
R8ybnpMcHa7CPWiLDMU5Lk3jqEyrKhpdb75bG8vQ=</CipherValue>
   </CipherData>
  </EncryptedData>
 </connectionStrings>

This is much more difficult to decipher than the plain XML web.config file. You should definitely consider using this new feature-it's easy and fast to use, and it adds more protection and security to your application.

Conclusion

In this article, I explained my reasoning behind deciding to deploy VS2005 and SQL Server 2005 within my company. I explained the benefits as I saw them, the new features that I liked, and some other new features that you might like. I walked you through how I upgraded one of my Visual Studio 2003, ASP.NET 1.1, and SQL Server 2000 applications to Visual Studio 2005, ASP.NET 2.0, and SQL Server 2005 as a test application. After discussing the upgrade process, I showed how to use the new GridView control to not only display data, but also allow sorting of every column without any code. Finally, I demonstrated how to use a new feature of ASP.NET 2.0 to encrypt the connection string section of the web.config file. I hope you had as much fun as I did.