Tag Archives: ASP.NET Membership

By default, when adding ASP.NET Membership to your web app a new ASP.NET Membership database will be created. However, in many circumstances you may wish the Membership database to be part of your main application database. To do this simply navigate to \Windows\Microsoft.NET\Framework\v2.0.50727 (use this path even if you are using ASP.NET 4.0 in your application as the Membership database has not changed since ASP.NET 2).

Then find and run the aspnet_regsql.exe program. This will bring up a dialog allowing you to specify the target database to incorporate the ASP.NET Membership tables and stored procedures :

The final step is to ensure that the all connection string references to the membership provider in the web.config point to this database. Don’t forget if you are using Roles that the role provider specified in the web.config must also point to this database (otherwise ASP.NET will automatically create a new database for the roles when the app is run).

ASP.NET Profiles were introduced to assist developers in persisting user information. Previous methods of persistence all had limitations in how they stored user data, Session state would only be held in memory and lost once the user’s session ended, a query-string would only be useful for that particular page and had to be recreated on each new page, cookies are only available on a single user machine. Profiles addressed all these difficulties by providing a simple persistent store which plugs into ASP.NET Membership. Profiles are ideal for storing user info such as preferences for a web app, besides being convenient they are very simple to use – just create them in the web.config file and access them anywhere in the application using Profile.ProfileName.

But with the convenience and power of Profiles comes a price – performance. Profiles are stored in a database, and therefore if used without caution can have a major performance cost.

To understand how best to use Profiles, first we will look at how they work under the hood. Profiles plug into the life-cycle of the page at two points:

The first time the Profile object is accessed in your code ASP.NET retrieves all the profile data for the current user from the database. If the profile data is used more than once in the same request ASP.NET reads it only once and then reuses it.

If profile data is updated, that update is deferred until the page has finished processing( ie after the PreRender, PreRenderComplete, and Unload events have completed). At that point the profile data is written to the database, thus multiple changes are updated in batch.

Thus, using Profiles can result in an extra two database hits per request (if Profile data is read and then updated) or one extra database hit (for simply reading the Profile data). It should be noted that Profiles do not have a caching mechanism so so every request for Profile data or update of Profile data requires a database connection.

Thus from a performance viewpoint, Profiles are best when:

There are a relatively small number of pages which access the Profile data.

Profiles only store small amounts of data (since accessing Profiles always results in the retrieval of all the Profile data for that user it can be quite result in large payloads).

Therefore to optimize performance when using ASP.NET Profiles it is best to combine

Profiles with other methods of state management. For example, a web app could first check if there was a cookie stored on the user’s machine for the user’s date format preference and if not available this data could be retrieved from the Profile (which would then then add a cookie) this will save a database round trip each time to check the preferences (session state could also be used for this).

ASP.NET Profiles are a very useful tool for persisting user data. Most other methods of state management do not easily persist the data across user visits, but Profiles plug seamlessly into the ASP.NET Membership database to provide a convenient persistent store.

Defining Profile Properties

The first step to using Profiles is to defining them in the web.config file. This is done by adding the <profile> section to the web.config file and the adding each property using a <add> element nested inside the <properties> element:

In addition to name the <add> element accepts several attributes which should be used. By default the format of the Profile is set to String but can be set to any datatype, for example the above JoinedDate profile should have a attribute of type added with the associated data type:

<add name="JoinedDate" type="System.DateTime" />

defaultValue is another useful attribute which sets the default of the Profile. For example, this could be used the set the initial language a user’s preferences is set to:

<add name="Language" defaultValue="en" />

There are several additional attributes, namely:

serializeAs : The format to use for serializing this Profile (String, CML, Binary, or ProviderSpecific)

readOnly : This is a boolean which sets if the Profile can be updated.

allowAnonymous : A boolean which sets if the Profile can be used with anonymous profiles.

provider : The profile provider that is used to manage this property.

Access Profiles

Profile access is very simple. Just use Profile.ProfileName anywhere in an app to get the profile value for the user. For example:

String langStr = Profile.Language

Update Profiles

Updating ASP.NET Profiles is also a simple procedure, just assign the value to the Profile and it will be stored:

Profile.Language = langTxtBox.Text

Note that the Profile will not actually be written to the database (and therefore not stored) until the page life-cycle is complete. Therefore after updating a Profile, avoid accessing it unless the page has finished processing (as only the old value will be stored).

Be aware that Profiles do not come without issues. There is a performance cost to using Profiles inappropriately see ASP.NET Profile Performance for more details.