How do I add an extra field using ASP.Net membership provider?

To add new column named "Address":

Step 1: Models/IdentityModels.cs

Add the following code to the "ApplicationUser" class:

public string Address{ get; set; }

Step 2: Models/AccountViewModels.cs

Add the following code to the "RegisterViewModel" class:

public string Address{ get; set; }

Step 3: Views/Register.cshtml

Add Address input textbox to the view:

<div class="form-group">
        @Html.LabelFor(m => m.Address, new { @class = "col-md-2 control-label" })
        <div class="col-md-10">
            @Html.TextBoxFor(m => m.Address, new { @class = "form-control" })
        </div>
</div>

Step 4 :

Go to Tools > NuGet Manager > Package Manager Console

Step A : Type “Enable-Migrations” and press enter
Step B : Type “ Add-Migration "Address" ” and press enter
Step C : Type “Update-Database” and press enter

i.e

PM> Enable-Migrations
PM> Add-Migration "Address"
PM> Update-Database

Step 5: Controllers/AccountController.cs

Go to Register Action and add "Address= model.Address" to the ApplicationUser i.e

 var user = new ApplicationUser { UserName = model.Email, Email = model.Email, Address= model.Address}

You're going to want to use the Profile Provider for this, thats what it was meant for. If you modify the membership provider to add the additional field it will break the provider contract and you won't be able to switch to another in the future.

Here is the profile provider: http://msdn.microsoft.com/en-us/library/2y3fs9xs.aspx
More info: http://msdn.microsoft.com/en-us/library/014bec1k.aspx

If you are using the sql membership provider than you probably have all the table structures installed to support the profile provider as well.

As jwsample noted, you can use the Profile Provider for this.

Alternatively, you could create your own table(s) that store additional user-related information. This is a little more work since you're on the hook for creating your own tables and creating the code to get and save data to and from these tables, but I find that using custom tables in this way allows for greater flexibility and more maintainability than the Profile Provider (specifically, the default Profile Provider, SqlProfileProvider, which stores profile data in an inefficient, denormalized manner).

Take a look at this tutorial, where I walk through this process: Storing Additional User Information.