Last night I attended the CapArea.net user group where Andrew Duthie showcased the ASP.NET Provider Model and used the SqlMembershipProvider as the main example.

Don't get me wrong. I am not whyning here. I simply want to be heard so that perharps the product can become even better.

There are tons of articles on the internet that speak very highly of the Membership API and I fully agree.

The issues I am going to outline are simply a "would be nice to have" rather than "it sucks because..."

So I hope you can keep an open mind while I point out some of the issues I have while developing against this API.

One User per Application

This one is probably the major issue. As you will find out as soon as you start looking into the API, both UserId and ApplicationId are unique identifiers. What this means is that you cannot share users across applications.

In my case, for instance, I have 3 applications that need to access the same user storage.

• A Web Application
• A Web Service
• A Windows Form (back-office) Application

With the current implementation of the Membership API I cannot use the out-of-the-box functionality to have the 3 applications authenticate against the same user.

ASPnet_Profile Storage

The profile properties (i.e: FirstName, LastName etc) are stored in a single field called PropertyNames and the values stored in PropertyValueString.
Both these fields are 'ntext 6000' fields and are parsed and properties constructed at run-time by the API

1. This method of storage will become an issue for large scale applications - for instance, you may run into performance degradations when your rows exceed the 100,000 marks (so I read somewhere). In my case, I have databases with users reaching the 2 million mark - yikes!
2. Unless you use the Membership API, you will have a hard time parsing out the fields in order to get the values. I have had to write SQL functions in order to achieve the desired results.

My suggestion here would be to store the Properties in another Table in a Name/Value pair format and therefore allowing for a more flexible membership API.