Do most people use .NET's SqlMembershipProvide

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'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 2

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.

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 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 5

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 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.