Membership class calls the "wrong" method on my custom provider?

Question

I have developed my own custom membership and role provider. The System.Web.Security.Membership class calls the CreateUser-method that I haven't implemented (on purpose, I want more information in my MembershipUser).

Should I use the Membership class at all in this scenario?

Now I typecast to my own membership provider to use my implemented CreateUser-method, is this the way to go? I feel a bit lost, how should I handle this?

((MyMembershipProviderBase)Membership.Provider).CreateUser(username, password, email, lastName, firstName, phoneNumber, out status);

Membership provider CreateUser-methods:

    public override MembershipUser CreateUser(string username, string password, string email, string passwordQuestion, string passwordAnswer, bool isApproved, object providerUserKey, out MembershipCreateStatus status)
    {
        throw new NotImplementedException();
    }

    public MyMembershipUser CreateUser(
        string username, string password, string email, string lastName, string firstName,
        string phoneNumber, out MembershipCreateStatus status)
    {
        // implemented...
    }

*Edit

Respons to @elkdanger comment.

Is this the kind of wrapper you are referring to in your comment?

Now the Membership class calls the standard CreateUser-method that redirects to my own implementation, the problem is that i cant set the additional information for the user (firstname, lastename and phonenumber). Is this the way to go and then handle setting the additional information from somewhere else(where i create my user)?

public override MembershipUser CreateUser(string username, string password, string email, string passwordQuestion,
        string passwordAnswer, bool isApproved, object providerUserKey, out MembershipCreateStatus status)
    {
        return this.CreateUser(username, password, email, "", "", "", out status);
    }

    public MyMembershipUser CreateUser(
        string username, string password, string email, string lastName, string firstName,
        string phoneNumber, out MembershipCreateStatus status

        )
    {
        var args =
   new ValidatePasswordEventArgs(username, password, true);

        OnValidatingPassword(args);

        if (args.Cancel)
        {
            status = MembershipCreateStatus.InvalidPassword;
            return null;
        }


        if (RequiresUniqueEmail && GetUserNameByEmail(email) != "")
        {
            status = MembershipCreateStatus.DuplicateEmail;
            return null;
        }

        MembershipUser u = GetUser(username, false);

        if (u == null)
        {

            try
            {
                status = Repository.CreateUser(username, EncodePassword(password), email, lastName, firstName,
        phoneNumber);
            }
            catch
            {
                status = MembershipCreateStatus.ProviderError;
            }
            return (MyMembershipUser)GetUser(username, false);
        }
        else
        {
            status = MembershipCreateStatus.DuplicateUserName;
            return null;
        }
    }

Answer 1

By casting in this way to get access to your particular instance, you're almost completely bypassing the point of the Asp.Net Membership system. The idea is that the system works with a known contract for managing its user data, and when you have to start casting in this way you're breaking that contract. I appreciate that it might be a small change, but never-the-less it's a bit of a "smell".

At this point you might as well run your own implementation because there will be no difference really, but you will save some time by just sticking with what you have.

If you want to clean this up a bit, I would revert back to the original CreateUser method that Asp.Net Membership gives you to overload, but create a wrapper around the membership functionality which enforces all the extra detail you need to pass in. If you can't do this (perhaps because you are using the default Create User wizard controls which come with Asp.Net) then I'd suggest your requirements out-grow what the Asp.Net Membership system caters for and you're better off in the long run devising your own system which is more suitable for what you're trying to achieve.

Good luck!