This article is the third article in the series of articles on the new personalization feature of ASP.NET 2.0, the Profile object.

The first article discussed the basics of a Profile object, how is it different from the Session object, and how to use simple properties in the Profile configuration section in the Web application configuration file (web.config).

The second article discussed more advanced features on how to use the Profile object, mainly, using custom defined objects as Profile objects.

In this article, we are going to discuss the Profile provider-model, which is a new concept implemented by most of the new features in ASP.NET 2.0. In addition, the default SQL Profile provider that is configured with SQL Server 2005 will be studied in depth, and I will present a trick on how to use the same provider with SQL Server 2000.

In the first two parts of this series on the new Profile object in ASP.NET 2.0, we explained the Profile object and implemented all the possible ways in which a Profile object can be configured in the Web application configuration file (web.config).

In this article, we will be looking at more advanced topics including the new Provider model in ASP.NET 2.0, the Profile provider, creating a custom Profile provider, and finally, how to configure the default Profile provider to work with SQL Server 2000.

What is a Provider Model?

The new provider model is an interface module between an ASP.NET 2.0 feature and the data store used to store the state of that feature. Providers in ASP.NET 2.0 abstract the physical data storage for a feature from the classes and the business logic exposed by a feature.

Some of the new features in ASP.NET 2.0 are based on a provider model in order to have access to the data store used. ASP.NET 2.0 ships with a default provider for each of the new provider-based features that are configured to work with SQL Server 2005 Express. However, if we want to make the features interact with another data store like SQL Server 2005, Oracle, or another database, then it is as simple as changing some configuration sections in the Web application configuration file (web.config) without having to change any single line of code in the features classes working each with its specific provider. More on the provider model can be found in this article: Introduction to the Provider Model

Importance of the Provider Model

The new provider model introduces several advantages in developing Web applications.

1. It isolates the new features controls from the data store used in the application. The only way for those controls to access the data store is by using that provider.
2. The application being developed can be used with any data source of choice without having to change any line of code in those features. We only need to create a custom provider and do some configuration changes in the Web application configuration file (web.config).

Profile Provider

The Profile feature has been designed with a provider-based model. The Profile feature ships with a provider for Microsoft SQL Server Express. You can create your own custom providers and configure them to work with the Profile feature. Pages that use the Profile objects will continue to work unchanged with your custom providers, since the Profile provider is a middle layer between the data store and the classes that provide the different methods to work with the Profile object.

More over, the Profile feature provides not only the Profile object but also a ProfileManager to manage the Web application Profile objects. This manager can handle both anonymous and authenticated Profile objects. Management of Profile objects includes the following:

1. Generating statistical information about all Profiles, for authenticated users, as well as for anonymous users.
2. Determining the number of Profiles that have not been modified in a given period of time.
3. Deleting individual Profiles as well as deleting multiple Profiles based on a Profile's last modification date.

The diagram below shows the different layers of the new Profile feature in ASP.NET 2.0:

Figure 1 - Profile Layer Diagram

As shown in Figure 1 above, the new Profile feature consists of three layers:

1. Profile classes that provide direct access to the Profile properties.
2. Profile providers that represent the abstraction layer between the upper layer which is the Profile classes and the lower layer which is the data store(s).
3. Profile Data Stores that represent the storage medium where the Profile property values are stored. In Figure 1 above, two main data stores are shown: the SQL Server and SQL Server Express. Any other data base can be added by just generating a custom Profile provider.

The ASP.NET 2.0 Profile provider implements all of the methods and properties that are part of the Profile object and ProfileManager class. Those methods and properties include the following.

1. ApplicationName is the application name using the Profile provider. Usually profile data are scoped to one application.
2. GetPropertyValues returns the profile property values from the data store used to store the Profile data.
3. SetPropertyValues stores the profile property values into the data store configured in the Web application.
4. DeleteProfiles deletes profile records stored inside the data store configured in the Web application.
5. DeleteInactiveProfile deletes inactive profile records stored inside the data store configured in the Web application.
6. GetNumberOfInactiveProfiles returns the number of inactive profile records inside the data store configured in the Web application.
7. GetAllProfiles returns a collection of ProfileInfo objects containing information about all profiles stored in the data store.
8. GetAllInactiveProfiles returns a collection of ProfileInfo objects containing information about all profiles stored in the data store that has not been accessed from a specific time.
9. FindProfilesByUserName returns a collection of ProfileInfo objects containing information about the profiles of a specific username.
10. FindInactiveProfilesByUserName is similar to the above method; however, it returns a collection of inactive profiles belonging to a certain username.

The above methods and properties are all implemented by the SQL Server Profile provider that is shipped with ASP.NET 2.0. This default Profile provider is configured to be used with SQL Server 2005. In the next section, we will discuss in detail how to make this default Profile provider work with SQL Server 2000.

User Profiles are configured to be stored in a Microsoft SQL Server 2005 Express database that is placed in the App_Code folder of an ASP.NET 2.0 Web application. The content of this folder is dynamically compiled at runtime.

User Profiles can be configured to communicate with another database store. User Profiles use the provider model; then it is easy to unplug the default provider and replace it with a custom provider.

ASP.NET 2.0 Beta 2 ships with one Profile provider which is the SqlProfileProvider. One can even create ones own custom Profile provider by inheriting from the ProfileProvider class. Sometimes, using an Oracle database for your Web application might be needed. What we need to do to make user Profiles work with an Oracle database is to create that custom Profile provider.

In this section, I will provide a step-by-step demonstration on how to configure the default provider which is the SqlProfileProvider to work with the Microsoft SQL Server 2000.

ASP.NET 2.0 framework ships with a utility used to configure an SQL Server 2000 database to store personalization information and mainly Profile information. This utility is named aspnet_regsql and is located in the following location:

{Drive Letter}:\Windows\Microsoft.NET\Framework\[.Net Framework]\

When this utility is run the first window that appears is shown in Figure 2 below.

Figure 2 - ASP.NET 2.0 SQL Server Setup Wizard

Press Next > and you will see Figure 3 below.

Figure 3. Configure or Remove a SQL Server for Application Services

Press Next > and you will see Figure 4 below.

Figure 4 - Specify Connection Information

A database named aspnetdb is chosen that was created previously using Microsoft SQL Server 2000 Enterprise Manager. In this section, we choose the computer name (server name), type of connection whether Windows authentication or SQL Server authentication, and finally the database instance where the tables representing the user Profile are to be stored. Hit Next > and continue the next simple steps.

By doing this process, the tables used by the Profile object to store users Profile features are saved on the SQL Server.

Once SQL Server is configured to be used to store the user Profiles, you need to update the Web.Config file so that the Profile configuration section will interact with the SQL Server 2000 and not with the SQL Server 2005 Express. Two ways to do this are offered below.

1. We can modify the LocalSqlServer connection string. If we check the Machine.Config file located at {Drive Letter:\Windows\Microsoft.Net\Framework\.NET Framework Version\CONFIG\}, we would notice the following ConnectionString configuration section:

<configuration 
  xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
  <appSettings />
 
  <connectionStrings>
    <remove name="LocalSqlServer"/>
    <add name="LocalSqlServer" connectionString="server=(local);
database=aspnetdb;Integrated Security=SSPI" 
      providerName="System.Data.SqlClient"/>
  </connectionStrings>
 
  <system.web>
 
    <authentication mode="Forms" />
 
    <anonymousIdentification enabled="true" />
 
    <Profile enabled="true">
      <properties>
        <add name ="Fname" allowAnonymous ="true" />
        <add name ="Lname" allowAnonymous ="true" />
      </properties>
    </Profile>
 
    <compilation debug="true" />
 
  </system.web>
</configuration>

In a previous section, we discussed the Profile provider and stated all of its properties and methods that are implemented and accessed by the Profile object and Profile Manager class.

In developing a custom Profile provider, you will need to implement the same methods and properties according to your data store used and the specific schema you have in your database design.

The default Profile provider that ships with ASP.NET 2.0 inherits from ProfileProvider base class. If we want to create a custom Profile provider we have to inherit from either the ProfileProvider or the AspNetSqlProfileProvider. If we want to have our Profile provider interact with a database different from SQL Server 2000/2005, then the ProfileProvider is the best choice. On the other hand, if the data store used is SQL Server 2000/2005 and what we want is just add some properties or methods to the existing Profile provider, then the latter is the best choice.

The ProfileProvider base class has the following structure shown in Listing 3 below:

Listing 3. ProfileProvider Basic Structure

public abstract class ProfileProvider : SettingsProvider

{

  public abstract int DeleteProfiles(ProfileInfoCollection profiles);

  public abstract int DeleteProfiles(string[] usernames);

  public abstract int DeleteInactiveProfiles(

    ProfileAuthenticationOption authenticationOption,
    DateTime userInactiveSinceDate);

  public abstract int GetNumberOfInactiveProfiles(

    ProfileAuthenticationOption authenticationOption,
    DateTime userInactiveSinceDate);

  public abstract ProfileInfoCollection GetAllProfiles(

    ProfileAuthenticationOption authenticationOption, int pageIndex,

    int pageSize, out int totalRecords);

  public abstract ProfileInfoCollection GetAllInactiveProfiles(

    ProfileAuthenticationOption authenticationOption,
    DateTime userInactiveSinceDate, int pageIndex,
    int pageSize, out int totalRecords);

  public abstract ProfileInfoCollection FindProfilesByUserName(

    ProfileAuthenticationOption authenticationOption, string usernameToMatch,

    int pageIndex, int pageSize, out int totalRecords);

  public abstract ProfileInfoCollection FindInactiveProfilesByUserName(

    ProfileAuthenticationOption authenticationOption, string usernameToMatch,

    DateTime userInactiveSinceDate, int pageIndex,
    int pageSize, out int totalRecords);

}

In the above listing, the ProfileProvider seems to inherit from the SettingsProvider. In addition to the methods inherited from the ProfileProvider, the custom Profile provider developer should also implement two other methods inherited from the SettingsProvider, which are the SetPropertyValues and GetPropertyValue. The structure of the SettingsProvider is shown below in Listing 4.

Listing 4. SettingsProvider Basic Structure

public abstract class SettingsProvider : ProviderBase

{

  // Properties

  public abstract string ApplicationName { get; set; }

  // Methods

  public abstract SettingsPropertyValueCollection GetPropertyValues(

    SettingsContext context, SettingsPropertyCollection properties);

  public abstract void SetPropertyValues(SettingsContext context,

    SettingsPropertyValueCollection properties);

}

As shown in the listing above, the two methods should be implemented by any custom Profile provider. In addition, if the Web application is scoped to interact with a set of Web applications, then the property called ApplicationName should also be implemented. If you are interested in how to implement such a custom profile, visit this online article: Profile Providers

In this third part of the series of articles on the Profile object, we discussed the provider model in ASP.NET 2.0. The importance of the provider model in Web development was briefly discussed. Then, the Profile provider was explained in detail, showing all the methods and properties constituting that provider. Next, a step-by-step procedure was demonstrated on how to configure the default Profile provider to work with SQL Server 2000. Finally, a brief discussion on how to develop a custom Profile provider was also presented at the end of the article.

Hope you enjoyed this article.

Happy DotNetting!