ASP.NET Profiles - Ready for Prime Time?

As a new feature in .NET 2.0 there was introduced a membership and profile framework. I spent today building some code around them, and generally I found them a mixed bag.

We run a web site at the foundation but we're not currently using a user profile management system. This is a feature we're looking at developing in order to be a gateway to customer self service.

So I followed ASP.NET best practices and implemented the membership and profile systems using the ASP.NET configuration tool, the web.config and threw the standard login, registration and forgot passwords onto a page and started playing with them.

Note: I'm not an expert Microsoft .NET developer (I'm a Director of IT, so I don't live and breath code 8 hours a day anymore), but I've been building profile systems in one way or another for probably about 10 years now. In the old days, we simply built our own using either an LDAP or database backed storage system to store a custom built login, profile, etc.

This is what I found was quite good with the framework:

1. The framework does a good job of implementing basic memberships. The basic schema of managing users, storage of passwords in an encrypted manner, and their roles and permissions are quite good out of the box. It didn't take me more than a couple hours to implement the out of the box controls for login, registration and forgot password as they tie in automatically with the underlying membership framework.

2. The ASP.NET controls are very flexible - like the other controls, they are template based so you can change all the steps, the styles and the fields within your page design.

So I thought I was doing well but then started looking at ASP.NET profiles. Here is where I found some pretty substantial frustrations:

1. Defining a profile using the web.config is clunky and takes a lot of debugging. No tooling support is provided for even basic data type configuration.

2. The supplied SQL provider for profiles is pretty weak. It stores your profile attributes as a set of name value pairs in a delimited list (the format is PropertyName:BS:StartIndex:Length for each property). I have no idea how the provider would efficiently search this especially if you have a large number of properties. If you want to write a more efficient provider, you can do so - see this article for a more efficient and database accessibly provider.

3. The only way to get properties defined is through hard coding them in the web.config. This seems like an inherently wrong place to put a schema definition. In addition, it means that you're going to lose the power of a database as the meta-data for each property is stored in the application but fattened down to generic name/value pairs in the database. I'm really not sure the value of this - does this make my life as a developer easier? Wouldn't it have been easier to create a strongly typed dataset? Or a gentle.net object? Or even a plain old .NET object that represents the profile? Then I get strong typing, proper debugging, etc.

4. Even more strange, this is what Studio does to your web.config metadata - it takes the data and generates a class out of it - except that it doesn't actually work in the new Web Application Project! After 3-4 hours of searching through the Internet, I found an Add-In that can generate the profile object that ASP.NET needs in order to work.

5. There used to be a profile tab in the ASP.NET configuration tool but it has disappeared. So the tooling that you have for memberships that allows you to create users, delete users, change data, etc. is missing for profiles - if you want to do profile management you have to write your own tooling.

6. Everything to do with the profile has to go through the API. As an architect, I love the idea of a business domain layer that hides the database and allows for flexibility around the underlying data store. But in practical terms, this is overkill for most of what I need and in many cases it would be easier just to have a basic table. We're not planning on switching our profile store from SQL Server to Oracle or to XML any time soon, so the solution is over-architected for our specific needs.

So at the end of day, what am I getting here? Is it really worth trying to iron out all this complexity for the minimal profile infrastructure I'm getting? Wouldn't it simply be easier to create a profile table, develop my own schema and simply hook it up to the member profile through the userID guid?

I'm still not satisfied with the idea of giving up on Microsoft standards since they tend to get better over time, but after 6-8 hours of playing with profiles, I'm not sure I'm gaining anything substantial here and I'm losing a lot in fighting with these APIs!