With the release of the ASP.NET Universal Providers, to supersede the existing SQL Provider types for managing Users, Roles, Profiles etc. for ASP.NET websites, and having installed these new providers via NuGet, which automatically will update you web.config file with all the necessary changes to make use of these new providers, it’s time to try and use them. Scott Hanselman has written an excellent article explaining what these changes are and a basic run through of how to use them, here. Having installed these new providers, I began attempting to use them, by using connecting up an existing aspnetdb database which had been used with the SQL Providers.
Initially, this does not work, as the new Universal Providers utilise a brand new database schema, which is created on-the-fly, by the Entity Framework, when the database is accessed for the first time. This is in contrast to the old style setup where, you had to run the aspnetregiis tool to populate an empty database with all of the objects required by the SQL Providers. The new schema is hugely simplified when compared to the old one. This basically boils down to removing the “aspnet” prefix from the names of all of the tables and having no Stored Procedures and Views.
However, the new Universal Providers do not drop any objects already existing within the database, so pointing it towards an existing SQL Provider database does not cause any damage to existing data. One thing to note is that if an object already exists within the database with the same name as an object to be created, the process fails silently, so watch out for that.
Once the new schema has been created, it’s time to migrate the data stored within the old tables into the new tables ready to use. In order to do this I ran this script in SQL Server Management Studio. This script did work for me, however, I am not guaranteeing it’s correctness or that it will not break anything on your system or result in data loss. So, please, check the script is appropriate for your environment, and run it at your own risk. Please also note, that this code sample does not migrate the Profile information.
With the data migrated into the newly created tables, I thought everything was good to go and attempted to run the website and login, only to be greeted with an incorrect password error message. This left me scratching my head, until I discovered Chris Kinsman’s blog post with an explanation of the problem. The SQL Providers, by default, use a SHA1 hash to store the password, but the Universal Providers use HMACSHA256 by default.
If you had been using SHA1 hashing previously, you need to configure the Universal Provider to use SHA1 hashing to be able to continue with the login data as is. This change is simple addition to your web.config file. Within web.config file, located the
<membership defaultProvider="AspNetSqlMembershipProvider" hashAlgorithmType="SHA1">
Run the application and login successfully.