A new ASP.
NET MVC project includes preconfigured Membership, Profile and RoleManager providers right out of the box. Try it yourself – create a ASP.
NET MVC application, crack open the web.config file and have a look.
First, you’ll find the ApplicationServices database connection:
<connectionStrings>
<add name="ApplicationServices"
connectionString="data source=.\SQLEXPRESS;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|aspnetdb.mdf;User Instance=true"
providerName="System.Data.SqlClient"/>
</connectionStrings>
Notice the connection string is referencing the aspnetdb.mdf database hosted by SQL Express and it’s using integrated security so it’ll just work for you without having to call out a specific database login or anything.
Scroll down the file a bit and you’ll find each of the three noted sections:
<membership>
<providers>
<clear/>
<add name="AspNetSqlMembershipProvider"
type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.
0.0.
0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
connectionStringName="ApplicationServices"
enablePasswordRetrieval="false"
enablePasswordReset="true"
requiresQuestionAndAnswer="false"
requiresUniqueEmail="false"
passwordFormat="Hashed"
maxInvalidPasswordAttempts="5"
minRequiredPasswordLength="6"
minRequiredNonalphanumericCharacters="0"
passwordAttemptWindow="10"
passwordStrengthRegularExpression=""
applicationName="/"
/>
</providers>
</membership>
<profile>
<providers>
<clear/>
<add name="AspNetSqlProfileProvider"
type="System.Web.Profile.SqlProfileProvider, System.Web, Version=2.
0.0.
0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
connectionStringName="ApplicationServices"
applicationName="/"
/>
</providers>
</profile>
<roleManager enabled="false">
<providers>
<clear />
<add connectionStringName="ApplicationServices" applicationName="/" name="AspNetSqlRoleProvider" type="System.Web.Security.SqlRoleProvider, System.Web, Version=2.
0.0.
0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
<add applicationName="/" name="AspNetWindowsTokenRoleProvider" type="System.Web.Security.WindowsTokenRoleProvider, System.Web, Version=2.
0.0.
0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
</providers>
</roleManager>
Really. It’s all there. Still don’t believe me. Run the application, walk through the registration process and finally login and logout. Completely functional – and you didn’t have to do a thing!
What else? Well, you can manage your users via the Configuration Manager which is hiding in Visual Studio behind Projects > ASP.
NET Configuration.
The ASP.
NET Web Site Administration Tool isn’t MVC-specific (neither is the Membership, Profile or RoleManager stuff) but it’s neat and I hardly ever see anyone using it. Here you can set up and edit users, roles, and set access permissions for your site. You can manage application settings, establish your SMTP settings, configure debugging and tracing, define default error page and even take your application offline. The UI is rather plain-Jane but it works great.
And here’s the best of all. Let’s say you, like most of us, don’t want to run your application on top of the aspnetdb.mdf database. Let’s suppose you want to use your own database and you’d like to add the membership stuff to it. Well, that’s easy enough. Take a look inside your [drive:]\%windir%\Microsoft.Net\Framework\v2.
0.50727\ folder. Here you’ll find a bunch of files. If you were to run the InstallCommon.sql, InstallMembership.sql, InstallRoles.sql and InstallProfile.sql files against the database of your choices, you’d be installing the same membership, profile and role artifacts which are found in the aspnet.db to your own database.
Too much trouble? Okay. Run [drive:]\%windir%\Microsoft.Net\Framework\v2.
0.50727\aspnet_regsql.exe from the command line instead. This will launch the ASP.
NET SQL Server Setup Wizard which walks you through the installation of those same database objects into the new or existing database of your choice. You may not always have the luxury of using this tool on your destination server, but you should use it whenever you can.
Last tip: don’t forget to update the ApplicationServices connectionstring to point to your custom database after the setup is complete.
At the risk of sounding like a smarty, everything I’ve mentioned in this post has been around for quite a while. The thing is that not everyone has had the opportunity to use it. And it makes sense. I know I’ve worked on projects which used custom membership services. Why bother with the out-of-the-box stuff, right? And the .
NET framework is so massive, who can know it all. Well, eventually you might have a chance to architect your own solution using any implementation you’d like or you will have the time to play around with another aspect of the
framework. When you do, think back to this post.
