Understanding the Profile Object of ASP.NET Version2, beta1
Author: Terry Voss, 

Why is the Profile Class (formally called Personalization) one of the most interesting new feature of ASP.NET version 2 for me? Because unlike membership, roles, and other personalization related areas it has much potential for general increase in state capability that is more efficient than we have had before in the generally stateless web application. Generally it is accepted good architectural advice to keep your app as stateless as possible to support scalability (doing just as well with more volume added), but state is what mainly differentiates us Web developers from the Windows developers in capability, so therefore it could potentially be very important to all aspects of web development.

The Session Object has been so valuable, and Profile has the potential to be an object that works alongside session to improve web applications control of state. Why not just create a session with a 2 year timeout? Because the session is very important for Authentication and Authorization. Running out to lunch and leaving your browser open could cause a read of all the companies passwords or other damage. So wouldn't it be nice if session could be used for that security purpose and if we had a strongly typed object, that was memorywise efficient, with an infinite timeout that we developer's can control. This is a simple description of the Profile object. Now because the profile object is strongly typed, at runtime we cannot add properties as we could with session. So there is no dynamic runtime change of structure with this Profile object. Planning ahead is the way to go here. Also, profile is more intelligent/efficient in the way it stores and reads data. Session always loads the whole session dictionary when you only want to query one value. Profile only looks up data when it is used. Why do I call it an object instead of a class? Because like the session object this Profile object is readily existent for our .ASPX pages. As the session object is held in the HttpContext.Current.Session property, the Profile object is held in the HttpContext.Current.Profile property. This means if you are not in a page object, then import System.Web.HttpContext, and use Current.Profile to access your properties with.

So setting/reading a profile property from a page object method is as simple as:

and if you are not on a page object but in a custom class method:

Comparing Profile and Session:
1) Both objects store separate data for each user of your web application without the developer having to worry about coding for such.
2) Session often needs a small timeout value to protect the user enough, while Profile only ends at the developer's discretion.
3) Profile allows control over clearing by inactive profiles versus active ones, time periods etc, while session is one or all.
4) Profile is strongly typed and Session is not.
5) At runtime a key can be added to Session, a property for Profile must be designed in before runtime.
6) Session must load the entire dictionary to read only one value, while Profile can read just one property efficiently (more scalable).
7) Both can store any kind of object as long as the object can be serialized.

Now Session can focus on Authentication/Authorization concerns, since we have a stronger candidate for storing statefulness.

Basic Knowledge:
System.Web.Profile namespace contains 17 classes/enumerations:
 1) DefaultHttpProfile (inherits HttpProfileBase, provides untyped access to profile properties)
 2) HttpProfileBase (provides untyped access to profile properties)
 3) HttpProfileGroupBase (provides untyped access to group profile properties)
 4) ProfileAuthenticationOption (enumeration:All, Anonymous, Authenticated)
 5) ProfileAutoSaveEventArgs (inherits eventargs)
 6) ProfileEventArgs (inherits eventargs)
 7) ProfileInfo (holds info about one user's profile)
 8) ProfileInfoCollection (holds info about all user's profiles)
 9) ProfileMigrateEventArgs (Provides event data for the MigrateAnonymous event of the ProfileModule class)
10) ProfileModule (noninheritable/sealed, implements IHttpModule)
11) ProfileProvider (mustinherit)
12) ProfileProviderAttribute (noninheritable/sealed, inherits Attribute)
13) ProfileProviderCollection (usual collection members, count, add)
14) SettingsAllowAnonymousAttribute (noninheritable/sealed, inherits Attribute)
15) AccessProfileProvider(I couldn't successfully instantiate this, could be Microsoft used class)
16) SqlProfileProvider (I couldn't successfully instantiate this, could be Microsoft used class)
17) ProfileManager (allows mgmt of profile info, like delete types, find types, get numbers of types, of profiles, most members are shared/static)

Use this important last class to manage either type of storage: MSAccess or MSSQLServer, as it has many valuable methods. Two other valuable classes are the ProfileInfo, and ProfileInfoCollection for reporting the user state status as you will see in later code samples.

If you create a new web project and immediately in the default.aspx file code-beside you type:

If you don't have Visual Studio, use the Profile tab of the Web Site Administration Tool (WAT) to manage how your site collects personal information about visitors. Profile properties represent data specific to a particular user. Using profile properties enables you to personalize your Web site for individual users. The html address for this web application is: http://localhost/AppFolderNameInWebsites/Webadmin.axd
 

Profile property groups allow you to group related profile properties together within a collection. For example, you may choose to group the Title property along with other properties such as First,  MiddleInitial, Middle, Last, Suffix, and in a property group called Name. In this example, you would set the value for the Suffix property with the following line of code:

Here is the associated web.config entries:

You can also create a custom type (class) that you use as a profile property. For example, you might have a class named ShoppingCart in a namespace called Sales that you can specify as a profile property and can then associate with each user in your application. So ShoppingCart can be a collection of ItemOrder classes. If you specify a custom type for your profile property, you must specify the fully qualified class name for the type so that ASP.NET can instantiate the class when the application runs. If the ShoppingCart class is defined in your Code folder with a namespace of sales, you would enter the following in the Fully qualified type name box under the Custom data type option:

You can also enable tracking by a generated unique ID for anonymous users of your site. This ID is stored in a cookie on the user's computer.

Note: (It is also possible to create custom profile providers. There are two primary reasons for creating a custom profile provider.
1) You need to store profile information in a data source that is not supported by the profile providers included with the .NET Framework, such as a FoxPro database, an Oracle database, or other data sources.
2) You need to manage profile information using a database schema that is different from the database schema used by the providers that ship with the .NET Framework. A common example of this would be user data that already exists in a SQL Server database for a company or Web site.)

After you create a SQLServer provider which is the preferred storage for a larger website for speed/scalability much more is added to your web.config.

Books:  (I own the following books below and therefore can attest that their quality is good on Version2 new features)

1. A First Look at ASP.NET v 2.0 by Alex Homer, et al (Paperback) Avg. Customer Rating: 2. Introducing ASP.NET 2.0 by Dino Esposito; (Paperback) Avg. Customer Rating: