ASP.NET Providers - Getting Started

This blog post is part of a series about the ASP.NET Providers (namely Membership, Role Management, and Profile).  The introductory post in the series can be found at the following link, which introduces the Provider Model pattern and gives a personal example of an implementation I have been working on:

This post will deal with getting started using the ASP.NET Providers by setting up a database.

Database Setup

First, you will need to configure a database to securely store all of the site’s user data and activity info.  You’ll most likely be content with the already provided SQL Providers (such as the SqlMembershipProvider), but Microsoft also provides you with other options in many cases.  For example in the case of Membership, you also have the option of having your site use the ActiveDirectoryMembershipProvider or you can even roll your own MembershipProvider.  The nice thing about using any of these Microsoft Providers is that they are already set up to store sensitive data like passwords in an encrypted format in the database.

There are two tools you can use to automatically generate the necessary database tables needed for the SQL implementation.  The first tool is a web-based configuration tool launched from Visual Studio called the ASP.NET Website Administration Tool. It can not only create the database tables, but can also configure authorization rules, user roles, user accounts, and many other settings that go right into your Web.config.  It is launched by selecting the ASP.NET Configuration menu option in the Project menu (or Website menu, depending on which version of Visual Studio you have or the project template you selected).  However, this tool will create the database in a SQL Server file named ASPNETDB.mdf placed in the site’s App_Data folder.  If you would prefer to create the database schema in an already existing install of SQL Server (likely on a different box), you need to use the aspnet_regsql.exe command-line tool.  The command-line tool’s graphical interface can be launched by typing the name of the executable in a Visual Studio Command Prompt (located in the Start Menu under Visual Studio | Visual Studio Tools).

The only other thing you need now is the connection string to this newly populated database.  I will show you where in your Web.config to put the connection string in the next post of this series.

Read On!

Continue onward by reading the next blog post in this series found at the following link:

Comments

Alan Blake
I needed to use the built-in authentication handling for only a single page and a single user (very simple). Therefore, I used the “location”
tag and the “credentials” tag to then add a user to my web.config you should consider adding this approach as well.

ASP.NET Providers - Membership, Role, and Profile

Seems like any website you start nowadays involves creating the same common features we see all over the web.  These include creating user account functionality, storing profile information, implementing role-based access to content and features, instantiating SQL tables and data access repositories, and so on, so forth.  In most cases it would be a complete waste of time and money to roll your own implementation every time.

There are plenty of frameworks out there that tackle this problem for you and abstract out details you shouldn’t have to worry about.  If you are in the .NET world, there are a set of these services available to you that are baked right into the .NET 2.0 Framework.  I’m going to show you a personal example of how easy it is to add some of this functionality to an existing site, even one with an antique and cumbersome architecture.  Implementing these features using the ASP.NET 2.0 Provider Model on said architecture has convinced me that it couldn’t be easier to add such functionality to a website, no matter what beast of a site you are dealing with.

ASP.NET 2.0 Provider Model

With the advent of ASP.NET 2.0, Microsoft introduced a set of configuration-driven services that adhere to the Provider Model pattern.  These services focus on storing application state of a website using a very flexible and extensible data access strategy.  The available features that can be added to your website include Membership (which includes authentication and authorization), Role Management, Profile, Session State, Web Parts Personalization, and Site Map navigation.  The whole idea is to be able to secure and enhance an existing site by dropping in a few lines into the Web.config, using a Microsoft utility to automatically create database tables (most likely your chosen storage medium), and then dropping, configuring, and skinning a few controls into your existing pages.  To read a more thorough introduction to the Provider Model and these ASP.NET 2.0 Provider services (including a few helpful diagrams), check out the following link:

Personal Example

We currently maintain a series of desktop products that we have been entrusted with.  Under the covers, these "desktop" products were originally written in Java as locally-hosted websites using Apache’s web server.  In order to be compatible with Windows Vista, we have since ported these products to .NET 2.0 and currently use UltiDev’s free, light-weight, and redistributable web server named Cassini (essentially the same thing as the development web server found in Visual Studio and a great alternative to IIS).  Many of the features are implemented in JavaScript and the content is almost entirely static HTML pages.  There were only a few Java Servlets that we ported to .NET HTTP Handlers and any database storage has been done using Microsoft Access databases.  This set of products also has other interaction requirements like the ability to view content from another product while staying in the context of the currently open product.  Finally, the installers for a few of these desktop products are getting to be nearly 600 MB in size, which has perpetuated the need for distributing the products to the users offline.

We are in the process right now of exploring the cost benefits and customer experience improvements in moving this set of offerings to an online suite of websites.  The first step we are taking is to build an online version of one of the products where users can obtain a user account to view the content.  Building new applications is one thing, but upgrading and maintaining existing applications (especially ones you have inherited) is a whole different development experience.  This is where my appreciation for the ease and flexibility of what Microsoft is offering comes into play.

Read On!

The rest of the blog posts in this series can be found at the following links:

In addition, I came across an issue when using the Profile system with the Web Application project template instead of the Web Site project template as found in Visual Studio’s default set of project templates.  It has to do with the Profile proxy class object not being auto-generated by Visual Studio when using the Web Application project template.  Read the following blog post for a discussion of the problem and it’s solution:

Also, I have another post discussing the advantages of using the ASP.NET Provider system under IIS 7 found in Windows Vista and Server 2008; it will also include some issues with using this system if some of your content is static HTML instead of ASPX pages.  You can find all of this goodness by following the link below:

Finally, I based my implementation on a 13-part tutorial series by Scott Mitchell on 4GuysFromRolla.com, starting at this link:

Enjoy!

Correctly Using Random Number Generators

Today I read another guy’s blog post that reminded me of my own "Aha!" moment I had a while back with Random Number Generators.  It’s something I will never forget about Random Number Generators but taken for granted, realizing that it might not be obvious to everyone how these objects are intended to be used.  Here is the blog entry that I read about creating and seeding a Random Number Generator once:

http://silverlight.net/blogs/msnow/archive/2008/12/01/silverlight-tip-of-the-day-77-creating-an-efficient-random-generator.aspx

However, I must admit that I think Mike Snow should have titled his post something similar to the title of my post.  And I will tell you why…

In the MSDN documentation that Mike quotes, there is a key sentence everyone needs to take note of, as you can ignorantly introduce bugs into your code:

"As a result, different Random objects that are created in close succession by a call to the default constructor will have identical default seed values and, therefore, will produce identical sets of random numbers."

I have actually build a piece of code where this has happened.  I wrote a for loop that iterated quickly enough that the construction of the Random objects resulted in identical random number seeds.  The result was that I asked for several random numbers in quick succession and got the same exact "random" number across all my requests each time I ran the code.  So not only did I get "identical sets of random numbers," but I got identical random numbers.

As Mike Snow and the MSDN documentation states (and from my own experience), Random Number Generators are designed to be constructed once and intended to live long and prosper within your application.  It can serve all of the random number needs within your application (i.e., you don’t need a different Random Number Generator for different use cases or different object types).  All you need is a one-time created random number seed and then you can forever generate random numbers of any type and within any range of numbers.  I can’t currently think of a situation when you may need to reseed your Random Number Generator.  Let me know if you think of one.