R – Hashed passwords and PasswordRecovery control

A1. If the membership settings in your web.config for App "A2" are pointing to the "DB1", this makes perfect sense, otherwise, this is not likely. Make sure that the ConnectionStringName property is pointing to "DB2" instead of "DB1"

A2. Intellisense would not work for a custom provider unless it is registered in the intellisense schema settings for your visual studio installation.

Here's some information on adding a Custom XSD for intellisense

It is an interesting point that email is part of the expected data fields.

Let me clarify... if you set RequiresUniqueEmail to true for the SQL Provider, the email will NOT be required --strictly speaking. It just means that every user will have to use a different email address from any other user. So there can be one user without an email address. A null value will be set in the database. But no other user would be able to omit the email address after that because that would cause two users to have null emails... So functionally it may as well be the same as required email addresses, but it is not technically the same.

The wizard controls provide a default UI for collecting membership information, and it assumes you use will be using the default SQL provider. If you are not using the default provider, your provider doesn't support all of the fields, or you have other unique constraints in your provider then you should customize the wizard steps with your own templates and handle the wizard's events to provide your own validations and additional logic as appropriate.

As for understanding the Membership system itself...

The Membership system in asp.net is a compromise between strict OO design and convenience. There are a few assumptions in the base MembershipProvider class from which the specific Membership providers inherit that are presumptuous. The fact that email addresses will be part of the membership data in one of the more liberal assumptions the base provider makes.

By making that assumption though, which is true in most environments, the membership system is able to expose some functionality related to email addresses in a simple and intuitive way (such as getting a user by their email address instead of user name and prohibiting multiple accounts with the same email address). If the base class didn't make that assumption, then every time you wanted to do stuff with emails in your specific provider, you'd have to cast the reference to the specific type you are using within your application. This is cumbersome.

From a purely OO point of view, these assumptions are uncomfortable. But you can, and many membership providers do, provide empty implementations for methods and properties from the base class if they don't use them.

You see this more with role providers... for example the Windows Token Role provider has a lot of members that throw NotImplmentedException (the Token role provider is a read-only provider for AD, so all of the property set accessors throw exceptions).