When I was in Cairo for the MDC a few weeks ago, I gave several talks that touched on the new membership controls in ASP.Net 2.0.  One question that came up repeatedly was how far can you stretch the provider before you have to write a custom membership provider.  The answer turns out to be not very far.  The provided membership providers are very good and very extensive, but they are also fairly rigid in their implementations. 

I think I have the 3 criteria that will force you to realize that you need to bite the bullet and write your own membership provider:

1. If you need to access your own schema that is different (in any way) from the schema provided.  Running Aspnet_regsql.exe creates a database and if you need to edit that schema then you cannot live without a custom provider except if you are adding tables for your own use, but bear in mind that the provider will just ignore your additions.


2. If you need to access data in someplace that is not supported.  Even if you want the same schema as the default providers support, you cannot use a proprietary database for that data and expect the providers to just work.  The XML provider is the most common example (though not very real world), but you could think of many scenarios including SQL 7.0 where a custom provider would be in order


3. If you need / want to insert some abstraction between the provider and the data.  Stefan Schackow of Microsoft had a great session at PDC 2005 in which he demonstrated creating a provider that allowed for the situation where your web servers were not in direct contact with the database server.  To solve that problem he wrote a provider that took a web service endpoint as its connection string.

So as you can see you are quite likely to find yourself having to write your own provider.  The good news is that it really isn’t that hard to do once you have done it once or twice