Do most people use .NET's SqlMembershipProvider, SqlRoleProvider, and SqlProfileProvider?

Question

Do most people use .NET's SqlMembershipProvider, SqlRoleProvider, and SqlProfileProvider when developing a site with membership capabilities?

Or do many people make their own providers, or even their own membership systems entirely?

What are the limitations of the SQL providers that would make you roll your own?

Is it easy to extend the SQL providers to provide additional functionality?

For Reference
Per Scott Gu's Blog, Microsoft provides the source code for the SqlMembershipProvider so that you can customize it, instead of starting from scratch. Just an FYI.

Answer 1

I normally use the providers that come out of the box, the main problem I have is querying across profile attributes across users. For example finding all users that have a profile attribute called Car that equals true. This is down to the way they are stored in the underlying structure.

Answer 2

In theory they sound nice, but not a chance if you do any unit testing without creating lots of abstract wrappers.

Answer 3

If you only need the basic user support (roles, profiles, etc.) then the default providers will work great.

If you need more customized support (data storage in a database not supported by the default providers [like Oracle], provider on a database that already exists, a heavily customized schema) then you should roll your own providers.

As for me, my current site only needed basic Roles support (and minimal Profiles support), so I went with the default providers.

Answer 4

I've rolled my own MembershipProvider classes using derived MembershipUser types to wrap the custom user schema, so profile-style properties are now available everywhere as part of the derived user via a cast.

Answer 5

I've used SqlMembership before and it's quite nice, unless you need something custom. I remember needing something like firstname and lastname info and I realised there're no fields for that. In the end instead of extending I've used Comment field of the provider and added name info to there. This is probably a bad practice/lazy/hack way but it worked for me in a tight situation..

Answer 6

We use everything except the Profile Provider. The Profile Provider is completly text based and does full text seearches - this becomes exceedingly slow as you user base gets larger. We have found it a much better solution to "role our own" profile section of the membership api database that is keyed to the userid in membership.

Answer 7

I have used both the custom classes and built in. When you need to get to a different database or schema or need to have extra info.

I abstracted out the layers so that it would work on the logic layer and have a DAL layer that used the data.common.dbprovider bit so it was reasonably generic.