Short Version
When upgrading from DNN 6.x to DNN 7.x, the installation wizard seems to miss an important setting in the web.config. It also does not delete old DLLs from the /bin/ folder. Because you are performing an upgrade rather than a clean installation, there are two versions of the AspNetMembershipProvider available, and the web.config may point to the wrong one.
Here is the fix. Update your web.config to change the AspNetMembershipProvider section so that it uses the DotNetNuke.dll assembly instead of the DotNetNuke.Provider.AspNetProvider.dll assembly.
<members defaultProvider="AspNetMembershipProvider"> <providers> <clear /> <add name="AspNetMembershipProvider" type="DotNetNuke.Security.Membership.AspNetMembershipProvider, DotNetNuke.Provider.AspNetProvider" providerPath="~\Providers\MembershipProviders\AspNetMembershipProvider\" /> </providers> </members>
After removing “.Provider.AspNetProvider” from the configuration, everything should work fine.
The Full Story
Yesterday I spent several hours debugging and fixing a DotNetNuke installation after upgrading from version 6.2.6 to 7.2.1. The upgrade appeared to work without any errors. However, when I tried to log in, I got an error. I tried searching around for a resolution. I found a number of similar complaints on the DNN forums but nobody had solved the problem.
Since I’m a software engineer, I decided to try to dig into the source code. I found the underlying error message and figured out that there was a problem occurring inside the UserController.cs class file. Whenever it would call MembershipProvider.Instance().UpdateUser(user) it would blow up with the error message, “System.ArgumentException: Parameter count does not match Parameter Value count.” I determined that this was due to a mismatch of C# code sending the wrong parameters to a stored procedure (dbo.UpdateUser).
I looked through the source and found that the only membership provider instance was AspNetMembershipProvider.cs. I tried setting breakpoints in that membership provider, but Visual Studio never reached them. I tried adding logging but nothing was output. I searched around Google some more, and here is the only workaround that I could find: http://www.itfunk.com/2013/08/26/dot-net-nuke-a-critical-error-has-occurred-an-unexpected-error-has-occurred/ That blogger suggested changing the stored procedure definition to fix the mismatch. But I was looking right at the database, and the C# code matched the stored procedure parameters.
Finally, a light bulb came on: The new AspNetMembershipProvider code was not being reached at all. I pulled up the source code for DNN 6 and compared it with DNN 7, and I found that the membership provider had been moved into the “main” DotNetNuke.dll assembly. Previously it was in its own assembly (DotNetNuke.Provider.AspNetProvider.dll). So there were two versions of the membership provider in the /bin/ folder, and the web.config was still pointing at the old DNN 6 version. I updated my web.config to point to the right assembly and VOILA! Problem solved.
In summary, upgraded DNN 7 installations may still be referencing the old DNN 6 authentication provider. This produces an error when the authentication provider calls the UpdateUser stored procedure during login. The DNN 7 version of the stored procedure has more parameters than DNN 6 did, causing the “parameter count” error. A simple web.config change (shown above) updates DNN to use the correct AspNetMembershipProvider.
Maybe I can send a bill for my consulting work to DNN Corp. 🙂