Evjen c12.tex V2 - 01/28/2008 2:25pm Page 587 Introduction to the Provider Model The ASP.NET provider model is an important framework to understand as you build your applications. The ASP.NET provider model was a major change introduced in ASP.NET 2.0, so you probably already know that ASP.NET is a way to build applications for the Internet. For the Internet means that an application’s display code travels over HTTP, which is a stateless proto- col. ASP.NET works with a disconnected architecture. The simple nature of this model means that requests come in and then responses are sent back. On top of that, ASP.NET does not differentiate one request from another. The server containing an ASP.NET application is simply reacting to any requestthrownatit. This means that a developer building a Web application has to put some thought into how users can remain in context between their requests to the server as they work through the application. Keeping a user in context means recording state, the state of the user, to some type of data store. This can be done in multiple ways, and no one way is the perfect way. Rather, you have to choose one of the available methods. You can read about maintaining state in an ASP.NET application in C hapter 22. State can be stored via multiple methods, some of which include: ❑ Application State ❑ Session State ❑ The Cache Object You use all these methods on the server, but you can also employ your own custom methods — such as simply storing state in a database using your own custom schema. It is also possible to write state Evjen c12.tex V2 - 01/28/2008 2:25pm Page 588 Chapter 12: Introduction to the Provider Model back to the clients, either directly on their computers or by placing state in the HTML output in the response. Some of these methods include: ❑ Cookies ❑ Querystrings ❑ Hidden Fields ❑ ViewState Understanding the Provider These methods work rather well; but most of them are rudimentary, and have short life spans. ASP.NET 3.5 includes a handful of systems (such as the new membership and role management systems) that handle state for users between multiple requests/response transactions. In fact, these systems require state management capabilities that go well beyond the limited time frames that are possible in the previously mentioned state management methods. Therefore, many of these systems must record state in more advanced modes — something that is easy to do in ASP.NET 3.5. Recording state to data stores in more advanced modes is accomplished through the use of providers. A provider is an object that allows for programmatic access to data stores, processes, and more. When working with ASP.NET 1.x, you might have encountered a rudimentary provider model that was present in the system. This provider model was an object that sat between the Session object and the actual place in which the sessions were stored. By default, sessions in ASP.NET are stored InProc , meaning in the same process where ASP.NET is running. In ASP.NET 1.x (and in ASP.NET 3.5 for that matter), you can simply change the provider used for the Session object; this will, in turn, change where the session is stored. The available providers for storing session information include: ❑ InProc ❑ StateServer ❑ SQLServer Besides InProc , you can use StateServer that enables you to store sessions in a process that is entirely separate from the one in which ASP.NET runs. This protects your sessions if the ASP.NET process shuts down. You can also store your sessions to disk (in a database for instance) using the SQLServer option. This method enables you to store your sessions directly in Microsoft’s SQL Server. How do you go about changing the provider that is used for sessions? You can do this in a couple of ways. One option to change the provider used for sessions is through the Internet Information Services (IIS) Manager, as shown in Figure 12-1. The other option is to go directly to a system-wide configuration file (such as the machine.config file) or to an application configuration file (such as the web.config ). In the file, change the name of the session state provider that is to be used within the < sessionState > section of the configuration document. 588 Evjen c12.tex V2 - 01/28/2008 2:25pm Page 589 Chapter 12: Introduction to the Provider Model Figure 12-1 Since ASP.NET 2.0, you have been able to take this provider model one step further than you ever could before. You discover this next. The Provider Model in ASP.NET 3.5 Back when ASP.NET 2.0 was being developed, plenty of requests came into the ASP.NET team. Users wanted to be able to store sessions by means other than the three methods — InProc , StateServer , and SQLServer . For instance, one such request was for a provider that could store sessions in an Oracle database. This might seem as if it’s a logical thing to add to ASP.NET in the days of ASP.NET 1.1. But if the team added a provider for Oracle, they would soon get requests to add even more providers for other databases and data storage methods. For this reason, instead of building providers for each and every possible scenario, the developers designed a provider model that enabled them to add any providers they wished. Thus, the new provider model found in ASP.NET was born. ASP.NET 3.5 includes a lot of systems that required state storage of some kind. Also, instead of record- ing state in a fragile mode (the way sessions are stored by default), many of these systems require that their state be stored in more concrete data stores such as databases or XML files. This also allows a longer-lived state for the users visiting an application — something else that is required by these systems. 589 Evjen c12.tex V2 - 01/28/2008 2:25pm Page 590 Chapter 12: Introduction to the Provider Model The systems based upon the provider model found in ASP.NET 3.5 that require advanced state management include the following: ❑ Membership ❑ Role management ❑ Site navigation ❑ Personalization ❑ Health monitoring Web events ❑ Web parts personalization ❑ Configuration file protection The membership system is a means to allow ASP.NET to work from a user store of some kind to create, delete, or edit application users. Because it is rather apparent that developers want to work with an unlimited amount of different data stores for their user store, they need a means to change the underlying user store for their ASP.NET applications easily. The provider model found in ASP.NET 3.5 is the answer. Out of the box, ASP.NET 3.5 provides a couple of membership providers that enable you to store user information. The included providers are the SQL Server and the Active Directory membership providers (found at System.Web.Security.SqlMembershipProvider and System.Web.Security.Active- DirectoryMembershipProvider , respectively). In fact, for each of the systems (as well as for some of the ASP.NET 1.x systems), a series of providers is available to alter the way the state of that system is recorded. Figure 12-2 illustrates these new providers. SqlPersonalizationProvider WebParts Membership Role SiteMap Profile SessionState WebEvents Configuration SqlMembershipProvider ActiveRoleMembershipProvider SqlRoleProvider WindowsTokenRoleProvider XmlSiteMapProvider SqlProfileProvider InProcSessionStateStore OutOfProcSessionStateStore SqlSessionStateStore SimpleMailWebEventProvider EventLogWebEventProvider TemplateMailWebEventProvider SqlWebEventProvider TraceWebEventProvider WmiWebEventProvider RSAProtectedConfigurationProvider DPAPIPProtectedConfigurationProvider ActiveDirectoryMembershipProvider ASP.NET Figure 12-2 590 Evjen c12.tex V2 - 01/28/2008 2:25pm Page 591 Chapter 12: Introduction to the Provider Model As you can see from the diagram, ASP.NET provides a large number of providers out of the box. Some systems have only a single provider (such as the profile system that includes only a provider to connect to SQL Server), whereas other systems include multiple providers (such as the WebEvents provider that includes six separate providers). Next, this chapter reviews how to set up SQL Server to work with a number of the providers presented in this chapter. You can use SQL Server 7.0, 2000, 2005, or 2008 for the backend data store for many of the providers presented (although not all of them). After this explanation, you review each of the available providers built into ASP.NET 3.5. Setting Up Your Provider to Work with Microsoft SQL Server 7.0, 2000, 2005, or 2008 Quite a number of providers work with SQL Server. For instance, the membership, role management, personalization, and other systems work with SQL Server right out of the box. However, all these systems work with the new Microsoft SQL Server Express Edition file ( .mdf ) by default instead of with one of the full-blown versions of SQL Server such as SQL Server 7.0, SQL Server 2000, SQL Server 2005, or SQL Server 2008. To work with either of these databases, you must set up the database using the aspnet_regsql.exe tool. Working with aspnet_regsql.exe creates the necessary tables, roles, stored procedures, and other items needed by the providers. To get at this tool, open up the Visual Studio 2008 Command Prompt by selecting Start ➪All Programs ➪Microsoft Visual Studio 2008 ➪Visual Studio Tools ➪Visual Studio 2008 Command Prompt. This gives you access to 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 many of the systems that are built into ASP.NET 3.5, such as the membership, role management, and personalization systems. The Setup Wizard provides two ways for you to set up the database: using a command-line tool or using a GUI tool. First, look at the command-line version of the tool. 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 intim- idated by it. You can get at the actual tool, aspnet_regsql.exe , from the Visual Studio Command Prompt if you have Visual Studio 2008. At the command prompt, type aspnet_regsql.exe -? to get a list of all the 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. Command Option Description -? Displays a list of available option commands. -W Uses the Wizard mode. This uses the default installation if no other parameters are used. -S < server > Specifies the SQL Server instance to work with. -U < login > Specifies the username to log in to SQL Server. If you use this, you also use the -P command. 591 Evjen c12.tex V2 - 01/28/2008 2:25pm Page 592 Chapter 12: Introduction to the Provider Model Command Option Description -P < password > Specifies the password to use for logging in to SQL Server. If you use this, you also use the -U command. -E Provides instructions to use the current Windows credentials for authentication. -C Specifies the connection string for connecting to SQL Server. If you use this, you can avoid using the -U and -P commands because they are specified in the connection string itself. -A all Adds support for all the available SQL Server operations provided by ASP.NET 3.5 including membership, role management, profiles, site counters, and page/control personalization. -A p Adds support for working with profiles. _R all Removes support for all the available SQL Server operations that have been previously installed. These include membership, role management, profiles, site counters, and page/control personalization. -R p Removes support for the profile capability from SQL Server. -d < database > Specifies the database name to use with the application services. If you don’t specify a name of a database, aspnetdb is used. /sqlexportonly < filename > Instead of modifying an instance of a SQL Server database, use this command in conjunction with the other commands to generate a SQL script that adds or removes the features specified. This command creates the scripts in a file that has the name specified in the command. 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 all -E After you enter the preceding command, the command-line tool creates the features required by all the available ASP.NET 3.5 systems. The results are shown in the tool itself, as you see in Figure 12-3. When this action is completed, you can see that a new database, aspnetdb , has been created in the Microsoft SQL Server Management Studio, which is part of Microsoft SQL Server 2005 (the database used for this example). You now have the appropriate tables for working with all the ASP.NET 3.5 systems that are able to work with SQL Server (see Figure 12-4). One advantage of using the command-line tool rather than the GUI-based version of the ASP.NET SQL Server Setup Wizard is that you can install in the database just the features that you are interested in working with instead of installing everything (as the GUI-based version does). For instance, if you are going to have only the membership system interact with SQL Server 2005 — not any of the other systems (such as role management and personalization) — then you can configure the setup so that only the tables, roles, stored procedures, and other items required by the membership system are established in the database. To set up the database for the membership system only, you use the following command on the command line. aspnet_regsql.exe -A m -E 592 Evjen c12.tex V2 - 01/28/2008 2:25pm Page 593 Chapter 12: Introduction to the Provider Model Figure 12-3 Figure 12-4 593 Evjen c12.tex V2 - 01/28/2008 2:25pm Page 594 Chapter 12: Introduction to the Provider Model The ASP.NET SQL Server Setup Wizard GUI Tool Instead of working with the tool through the command line, you can also work with a GUI version of the same wizard. 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 12-5. Figure 12-5 Clicking Next gives you a new screen that offers two options: one to install management features into SQL Server and the other to remove them (see Figure 12-6). From here, choose the Configure SQL Server for application services and click the Next button. The third screen (see Figure 12-7) asks for the login credentials to SQL Server and the name of the database to perform the operations. 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. After you have made your server and database selections, click Next. The screen shown in Figure 12-8 asks you to confirm your settings. If everything looks correct, click Next — otherwise, click Back and correct your settings. 594 Evjen c12.tex V2 - 01/28/2008 2:25pm Page 595 Chapter 12: Introduction to the Provider Model Figure 12-6 When this is complete, you are notified that everything was set up correctly. Connecting Your Default Provider to a New SQL Server Instance After you set up the full-blown Microsoft SQL Server to work with the various systems provided by ASP.NET 3.5, you create a connection string to the database in your machine.config or web.config file. This is illustrated in Listing 12-1. Listing 12-1: Changing the connection string in the machine.config.comments or your web.config file to work with SQL Server 2005 <configuration> <connectionStrings> <add name="LocalSqlServer" connectionString="Data Source=127.0.0.1;Integrated Security=SSPI" /> </connectionStrings> </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 595 Evjen c12.tex V2 - 01/28/2008 2:25pm Page 596 Chapter 12: Introduction to the Provider Model Figure 12-7 machine.config file changes how each and every ASP.NET application uses this provider. Applying this setting in the web.config file causes only the local application to work with this instance. After the connection string is set up, look further in the < providers > section of the section you are going to work with. For instance, if you are using the membership provider, you want to work with the < membership > element in the configuration file. The settings to change the SQL Server are shown in Listing 12-2. Listing 12-2: Altering the SQL Server used via configuration <configuration> <connectionStrings> <add name="LocalSql2005Server" connectionString="Data Source=127.0.0.1;Integrated Security=SSPI" /> </connectionStrings> <system.web> <membership defaultProvider="AspNetSql2005MembershipProvider"> <providers> 596 . the Session object and the actual place in which the sessions were stored. By default, sessions in ASP. NET are stored InProc , meaning in the same process where ASP. NET is running. In ASP. NET 1.x (and in ASP. NET. following command on the command line. aspnet_regsql.exe -A m -E 59 2 Evjen c12.tex V2 - 01/28/2008 2:25pm Page 5 93 Chapter 12: Introduction to the Provider Model Figure 12 -3 Figure 12-4 5 93 Evjen. a means to change the underlying user store for their ASP. NET applications easily. The provider model found in ASP. NET 3. 5 is the answer. Out of the box, ASP. NET 3. 5 provides a couple of membership