Is it worth using the built-in membership framework in your ASP.Net application, or should you roll your own? I’ve been trying it out recently, and I have mixed feelings.

On the plus side, it does get you up and running quickly with user login and role-based permissions, saving time and possibly achieving more reliable results, on the grounds that Microsoft and countless other users should have found and fixed any bugs by now.

One the negative side, there are annoying limitations. The most obvious one is that a user as defined in the framework only has a minimal number of fields, not including information you probably want to store like first and last name. You are meant to fill this gap by using profiles, another ASP.Net feature which lets you store arbitrary name-value pairs in a database as a kind of persistent session. That works, but the way profile properties are stored makes it hard to do things like sorting users by last name. Therefore, you will probably end up managing your own user database and joining it to the membership system with the user ID, at which point you begin to lose some of the benefits.

Some of the supplied controls, like the CreateUserWizard, seem rough-and-ready too.

Still, the real fun began when I tried to deploy my demo app to Server 2008 and SQL Server Express 2008. By the way, make sure you install .NET Framework 3.5 SP1 and Windows Installer 4.5 before installing the latest SQL Server Express, otherwise the setup spends ages unpacking its files and then exits with a brief message. I got there eventually, copied my application across, and optimistically tried to run it.

When you debug a web application in Visual Studio, it defaults to a SQL Express database in the App_Data folder within the web site, attached on demand. In theory, that should make it easy to deploy to another machine with SQL Express installed: just copy it across, right? There must be a way of getting this to  work, but it seems a lot of people have problems. I got the message:

Login failed for user ‘NT AUTHORITY\NETWORK SERVICE’.

This makes sense, insofar as ASP.NET runs as this user. I temporarily attached the database and added the login, to be rewarded with a different and more perplexing error:

Failed to generate a user instance of SQL Server due to a failure in starting the process for the user instance.

A quick Google shows that many users have suffered from these errors, and that a large number of remedies have been proposed. I abandoned the idea of attaching the database on demand and set up a new database, made ready with Aspnet_regsql. I still got one or other of these errors.

Eventually I realised that my application was using more than one connection string. The problem is that the membership framework uses three different "providers", one for membership, one for roles, and one for profiles. By default in IIS 7.0, these all use an attach-on-demand connection string, defined as LocalSqlServer, and inherited from machine.config buried deep within your Microsoft .NET Framework system folder. In order to prevent ASP.Net membership from using this, you have to override all three providers in the web.config for your application. There’s an example in this article from ISP MaximumASP. I wish I’d come across it sooner; but my demo works fine now.