Personalization

Personalization Providers

As shown in Figure 9-1 earlier in the chapter, the middle tier of the Personalization model, the Personalization Services layer, communicates with a series of default data providers. By default, the Personalization model uses Microsoft Access for storing the personalization properties that you define. You are not limited to just this type of data store, however. Other built-in data providers include a Microsoft SQL Server data provider that enables you to work with Microsoft SQL Server 7.0, 2000, and SQL Yukon. Besides the Microsoft Access and SQL Server data providers, the architecture allows you to create your own data providers if one of these data stores doesn’t fit your requirements.

Working with the Access personalization provider

The first data provider is the Microsoft Access data provider. This is the default provider used by the personalization system provided by ASP.NET. When used with Visual Studio 2005, the IDE places the AspNetDB.mdb file within your application’s Data folder.

As you look through the machine.config file, note the sections that deal with how the personalization engine works with the Microsoft Access database. In the first reference to the Access file that it works with, you find a connection string to this file (shown in Listing 9-17) within the <connections> section located in the <system.web> section of the file.

Listing 9-17: The connection string to the Access file in the machine.config file

<configuration>

<system.web>

<connectionStrings>

<add name=”AccessFileName” connectionString=”~\DATA\ASPNetDB.mdb” /> </connectionStrings>

</system.web>

</configuration>

In this example, you see that a connection string with the name of AccessFileName has been defined. The location of the file, specified by the connectionString attribute, points to the relative path of the file. This means that in every application you build that utilizes the new personalization capabilities, the default Access provider should be located in the application’s Data folder and have the name of

ASPNetDB.mdb.

The Access file’s connection string is specified through the AccessFileName declaration within the <connectionStrings> section. You can see the Personalization engine’s reference to this in the <profile> section within the machine.config file. The <profile> section here includes a subsection listing all the providers available to the Personalization engine. This is shown in Listing 9-18.

Listing 9-18: The Access data provider

<configuration>

<system.web>

<profile enabled=”true” defaultProvider=”AspNetAccessProvider”

(continued)

281

Chapter 9

Listing 9-18: (continued)

inherits=”System.Web.Profile.HttpProfileBase, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a”>

<providers>

<add name=”AspNetAccessProvider” type=”System.Web.Profile.AccessProfileProvider, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a” connectionStringName=”AccessFileName” applicationName=”/”

description=”Stores and retrieves profile data from the local Microsoft Access database file” />

</providers>

</profile>

</system.web>

</configuration>

From this, you can see that a provider is added by using the <add> element. Within this element, the connectionStringName attribute points to what was declared in the <connectionString> attribute from Listing 9-17.

To specify an entirely different Microsoft Access file other than the one specified in the machine.config file, first create a connection string which points to an Access file that is a templated version of the

AspNetDB.mdb file. You can find this template file at C:\WINDOWS\Microsoft.NET\Framework\ v2.0.xxxxx\ASPNetdb_Template.mdb. Just copy this file and locate the copy where you want. At this point, you can use the <connectionString> to point to this new Access file. If you change these values in the machine.config file, all the ASP.NET applications that reside on the server use this Access file. If you make the changes only to the web.config file, however, only the application that is using this particular web.config file uses this new data store. Other applications on the server remain unchanged.

Working with the SQL Server personalization provider

Although the Access personalization provider is the default provider when you work with the personalization framework, when you work with larger applications that require the factors of performance and reliability, you want to use the SQL Server personalization provider. If this data store is available, you should always try to use this option instead of the default Access personalization provider.

If you worked with the Access personalization provider I explained earlier, you probably found it easy to work with. It works with the personalization provider right out of the box — without any set up or configuration on your part. Using the SQL Server personalization provider is a bit of a different story.

Although it is not difficult to work with, you must set up and configure your SQL Server before using it.

ASP.NET 2.0 provides three ways to set up and configure SQL Server for the personalization framework. The first way is through the Web Administration Tool, which is explained in detail in Chapter 14. The second way is through the ASP.NET SQL Server Setup Wizard, and the last method is by running some of the SQL Server scripts provided with the .NET Framework 2.0.

Using the ASP.NET SQL Server Setup Wizard

The ASP.NET SQL Server Setup Wizard is an easy-to-use tool that facilitates setup of the SQL Server to work with the personalization framework. The Setup Wizard provides two paths to set up the database — through the use of a command-line tool or through the use of a provided GUI tool.

282

Personalization

The ASP.NET SQL Server Setup Wizard command-line tool

The command-line version of the Setup Wizard gives the developer optimal control over how the database is created. Working from the command-line using this tool is not difficult, so don’t be intimidated by it.

You can get at the actual tool, aspnet_regsql.exe, from the Visual Studio Command Prompt. You can find this command prompt at Start All Programs Microsoft Visual Studio Whidbey Visual Studio Tools Visual Studio Command Prompt. At the command prompt, type aspnet_regsql.exe -? to get a list of all the available command-line options at your disposal for working this tool.

The following table describes some of the available options for setting up your SQL Server instance to work with the personalization framework.

283

Chapter 9

To modify SQL Server to work with the personalization provider using this command-line tool, you enter a command such as the following:

aspnet_regsql.exe –A p –E

After you enter the preceding command, the command-line tool creates the profile features required. The results are shown in the tool itself as you see in Figure 9-4.

Figure 9-4

When this action is completed, you can see that, in fact, a new table, aspnetdb, has been created in the SQL Server Enterprise Manager. It now contains the appropriate tables for working with the personalization framework (see Figure 9-5).

Figure 9-5

284

Personalization

The ASP.NET SQL Server Setup Wizard GUI tool

Instead of working with this tool through the command-line, another option is to work with the same wizard through a GUI version of it. To get at the GUI version, type the following at the Visual Studio Command Prompt:

aspnet_regsql.exe

At this point, the ASP.NET SQL Server Setup Wizard welcome screen appears, as shown in Figure 9-6.

Figure 9-6

Clicking the Next button gives you a new screen that provides you with two options — one to install management features into SQL Server and the other to remove them (see Figure 9-7).

Chapter 9

From here, choose the Configure SQL Server for ASP.NET SQL Server Features and click the Next button. The third screen (see Figure 9-8) asks for the login credentials to SQL Server and the name of the database to perform the operations. When you pull it up, the Database option is <default> — meaning that the wizard creates a database called aspnetdb. If you want to choose a different folder, such as the application’s database, choose the appropriate option.

Figure 9-8

After you have made your server and database selections, click Next. The screen shown in Figure 9-9 asks you to confirm your settings. If everything looks correct, click the Next button — otherwise click Back and correct your settings.

When you’re finished, you get a notification that everything was set up correctly.

Using SQL scripts to install personalization features

Another option is to use the same SQL scripts that these tools and wizards use. If you look at C:\WINDOWS\Microsoft.NET\Framework\v2.0.xxxxx\, from this location, you see the install and remove scripts — InstallPersonalization.sql and UninstallPersonalization.sql. Running these scripts provides your database with the tables needed to run the personalization framework.

Setting up your application to use a SQL Server personalization provider

Now SQL Server is set up to work with the personalization capabilities provided by ASP.NET 2.0. The personalization framework understands how to work with SQL through settings that are in the machine.config or web.config files.

286

Personalization

Figure 9-9

If you look in the machine.config file, you find the connection string to SQL Server is specified in the <connectionStrings> section of the document, as shown in Listing 9-19.

Listing 9-19: The connection string to SQL Server in the machine.config file

<configuration>

<system.web>

<connectionStrings>

<add name=”LocalSqlServer”

connectionString=”data source=127.0.0.1;Integrated Security=SSPI” /> </connectionStrings>

</system.web>

</configuration>

You may want to change the values provided if you are working with a remote instance of SQL Server rather than an instance that resides on the same server as the application. Changing this value in the machine.config file changes how each and every ASP.NET application uses this provider.

After the connection string is set up accordingly, look further in the <providers> section of the <profile> element. You see the settings for SQL Server, as shown in Listing 9-20.

Listing 9-20: The SQL Server data provider

<configuration>

<system.web>

<profile enabled=”true” defaultProvider=”AspNetAccessProvider”

(continued)

287

Chapter 9

Listing 9-20: (continued)

inherits=”System.Web.Profile.HttpProfileBase, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a”>

<providers>

<add name=”AspNetSqlProvider” type=”System.Web.Profile.SqlProfileProvider, System.Web, Version=2.0.3600.0, Culture=neutral,

PublicKeyToken=b03f5f7f11d50a3a” connectionStringName=”LocalSqlServer”

applicationName=”/” description=”Stores and retrieves profile data from the local Microsoft SQL Server database” />

</providers>

</profile>

</system.web>

</configuration>

With this addition, SQL Server is now added as one of available providers to use with your applications. The name of this provider instance is AspNetSqlProvider. You can see that this instance also uses the connection string of LocalSqlServer, which was defined in Listing 9-19.

Now that the SQL Server provider is in place and ready to use, you have to make only a minor change to the web.config file of your application in order for your application to take advantage of what you have established. Listing 9-21 shows the <profile> section of the web.config file.

Listing 9-21: Using SQL Server as the provider in the web.config file

<configuration>

<system.web>

<profile inherits=”System.Web.Profile.HttpProfileBase, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a”

defaultProvider=”AspNetSqlProvider”>

<properties>

<add name=”FirstName” /> <add name=”LastName” /> <add name=”LastVisited” /> <add name=”Age” />

<add name=”Member” />

</properties>

</profile>

</system.web>

</configuration>

The only change necessary is to use the defaultProvider attribute and give it a value that is the name of the provider you want to use — in this case the SQL Server provider, AspNetSqlProvider. You could have also made this change to the machine.config file by changing the <profile> element as shown in Listing 9-22.

288