You have a few choices. One is as was suggested, just change the template. Another (and better, although much more work) would be to pop open the control in reflector to see how it works, then extend it and override the relevant bits to remove references to password.
The third (and what I would recommend) is to just roll your own. The Membership, Roles, and Profile classes are all fairly easy to work with, and the CreateUserWizard is fairly heavy weight. Unless it is exactly what I need, I usually throw together a user control that does it anyways, even when using the default provider.
Access modifiers
From docs.microsoft.com:
public
The type or member can be accessed by any other code in the same assembly or another assembly that references it.
private
The type or member can only be accessed by code in the same class or struct.
protected
The type or member can only be accessed by code in the same class or struct, or in a derived class.
private protected (added in C# 7.2)
The type or member can only be accessed by code in the same class or struct, or in a derived class from the same assembly, but not from another assembly.
internal
The type or member can be accessed by any code in the same assembly, but not from another assembly.
protected internal
The type or member can be accessed by any code in the same assembly, or by any derived class in another assembly.
When no access modifier is set, a default access modifier is used. So there is always some form of access modifier even if it's not set.
The static modifier on a class means that the class cannot be instantiated, and that all of its members are static. A static member has one version regardless of how many instances of its enclosing type are created.
A static class is basically the same as a non-static class, but there is one difference: a static class cannot be externally instantiated. In other words, you cannot use the new keyword to create a variable of the class type. Because there is no instance variable, you access the members of a static class by using the class name itself.
However, there is a such thing as a static constructor. Any class can have one of these, including static classes. They cannot be called directly & cannot have parameters (other than any type parameters on the class itself). A static constructor is called automatically to initialize the class before the first instance is created or any static members are referenced. Looks like this:
static class Foo()
{
static Foo()
{
Bar = "fubar";
}
public static string Bar { get; set; }
}
Static classes are often used as services, you can use them like so:
MyStaticClass.ServiceMethod(...);
Best Answer
There are two options I can see, both of which will yield basically the same result:
FK from
dbo.aspnet_User.UserIDtodbo.Profile.UserID, then define a unique key ondbo.Profile.UserID(unless you use it as the PK column fordbo.Profile)FK from
dbo.aspnet_Profile.ProfileIDtodbo.Profile.ProfileIDdbo.aspnet_Useris logically 1 - 1 withdbo.aspnet_Profile, so it doesn't really matter which approach you use as you will still get the same relational integrity.If you are replacing the standard profile data table with your own implementation then it makes more sense to use the first suggestion, otherwise if you are extending the Profile schema then use the second suggestion.
EDIT
aspnet_Profileis the standard table - the standardSqlProfileProviderstores the user's profile data as a serialized property bag inaspnet_Profile, hence why there is no separateaspnet_ProfileDatatable as well.This approach allows the profile schema to be customized easily for different applications without requiring any changes to the underlying database, and is the most optimal solution for a framework such as .NET. The drawback is that SQL Server does not have easy access to this data at all, so it is much more difficult to index, update and query the user's profile data using T-SQL and set-based logic.
The most common approach I have seen to remove this limitation is to extend the standard
SqlProfileProviderto write to a custom profile data table which has specific columns for application-specific profile properties. This table naturally has a 1-1 relationship with the aspnet_Profile table, so it has a foreign key as indicated above.The role of the extended provider is to promote specific profile properties to columns during profile writes, and read in the columns when the profile is retrieved.
This allows you to mix-and-match storage solutions on an as-needs basis, as long as your extended provider knows how to fall back to the standard implementation where it does not 'know' about a given property.
I always think it is best to leave the standard membership tables as-is, and extend where necessary using new tables with appropriate foreign keys, then subclass the appropriate provider and override the provider methods with your own implementation (calling into the base implementation wherever possible).