Fix for Login Error After DNN 7 Upgrade

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.  🙂

Advertisements

Version 4.0.1 of PLINQO Released

Okay, I’m a little behind on blogging. Since I previously wrote multiple posts regarding PLINQO (Professional LINQ-to-SQL), I wanted to drop a quick update that version 4.0.1 was recently released. I also skipped writing about the release of version 4.0.0 because I couldn’t find a definitive enhancement list. I stumbled across it today, so I’m posting both.

Version 4.0.0 Highlights:

  • Futures Support – Allows creation of a queue of objects to be loaded all at once. This differs from the old Multiple Result Sets feature in that it defers execution until the data is really needed. It’s also easier to support more than 2 result sets in a single call.
  • Caching Improvements – Added support for various caching providers including Memcached.
  • Detach/Attach Entities – Added more methods for serialization/deserialization so detached entities can be stored as binary or XML.
  • More DetailsClick here for the full set of enhancements

Version 4.0.1 Highlights:

  • DataContextName – You can finally control the name of the DataContext that is generated. This is long overdue and greatly appreciated.
  • Pagination Improvements – Added methods for NextPage, PreviousPage and GoToPage for PagedList.
  • Null Handling – Added NotNull rule and attribute and improved SQL queries that use null comparisons.
  • More DetailsClick here for the full set of enhancements

I know that some people are a little hesitant of continuing to use LINQ-to-SQL (L2S) given Microsoft’s shift in direction to LINQ-to-Entities (L2E). However, Microsoft has not dropped support for L2S in .NET 4.0. They actually added some features to LINQ-to-SQL in the recent release of .NET 4.0 and Visual Studio 2010. L2S is widely adopted and (from what I can tell) MS intends to continue supporting it in future versions of .NET, even though they aren’t going to develop it further.

At this time, the PLINQO team intends to provide LINQ-to-Entities support in a future release. This means that PLINQO users should require little-to-no-work in making the switch to L2E. In the meantime, I’m happy using PLINQO as my primary OR/M on new projects.

Kick it on DotNetKicks.com [Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

PLINQO 3.0 – Even Better

I wrote a blog article a few months ago giving kudos to the guys at CodeSmith after my discovery of PLINQO 2.0. Since then, I haven’t done much with LINQ-to-SQL because the legacy projects at my day job use Castle ActiveRecord with NHibernate. But I recently started a new project (giving me the freedom to investigate other technologies) and was pleasantly surprised to find PLINQO 3.0. In addition to a new major code revision, I found that CodeSmith released a new website with more information about the benefits of PLINQO and sample usage.

In case you’re not familiar with PLINQO, this set of code-generation templates is designed to enhance the LINQ-to-SQL development experience. They’re not only a time-saver like most code generation templates, but they allow you to overcome many of the limitations of “raw” LINQ-to-SQL. See Does LINQ StinQ? Not with PLINQO!

My first article covered some of the main benefits of PLINQO 2.0, including:

  • Generates one file per entity instead of one massive DBML file.
  • Generates partial classes where custom code can be written and won’t be overwritten.
  • Generated entity files are added to the project as code behind files to their corresponding custom entity files.
  • Adds customizable business rules engine to enforce entity validation, business and security rules.
  • Generation of entity manager classes… Provides access to common queries based on primary keys, foreign keys, and indexes.
  • Ability to automatically remove object prefix and suffixes (ie. tbl and usp) [based on RegEx].

In addition to those features, PLINQO 3.0 has the following benefits:

  • Entity Detach – Detach entities from one DataContext and attach to another (very useful for caching scenarios).
  • Entity Clone – Create copies of entities in-memory, set only the properties that need to be changed and persist as a new object with a new primary key.
  • Many-to-Many Relationships – Yes, M:M can be done in LINQ-to-SQL without writing goofy code to manage the link tables.
  • Auditing – The app can track all property changes complete with a copy of the old value and new value. Tracked changes can be read iteratively or dumped to an XML string.
  • Batch Updates and Deletes – You can perform updates and deletes on records based on criteria on the SQL Server without pulling each record into your app first. I’d already been using another implementation of this concept, but it’s nice to have it built into PLINQO.
  • Multiple Result Sets – PLINQO can pull multiple recordsets back in a single request. This can be done either by using a stored procedure or using the ExecuteQuery method passing a list of queries as parameters.

I think some of those benefits may have existed in the 2.0 release, but weren’t documented. I’m glad to see they’re starting to provide more documentation and samples. It would still be nice to see more, however (as it occurs to me) your custom PLINQO code really sits on top of LINQ-to-SQL, so all of the standard LINQ documentation applies.

I do have some suggestions for CodeSmith to implement in future versions of PLINQO:

  • I’m fond of the IRepository pattern because of unit testing with frameworks such as Rhino Mocks. I’ve seen a couple of implementations of IRepository with LINQ (example 1, example 2). This should be a code generation option.
  • I’d like to see a DataContext session factory with per-web-request lifestyle. This is available in other ORM systems like ActiveRecord. After some digging, I found an example of this that also demonstrates integration with Microsoft’s MVC and Castle Windsor (IoC). Sweet.
  • There are some helpful LINQ libraries out there, such as LINQKit and the LINQ Dynamic Query Library. It would be nice to include these and/or other free libraries with PLINQO.
  • I’ve gotten the impression that Microsoft is going to favor the Entity Framework (LINQ-to-Entities) over LINQ-to-SQL. I’d love to see PLINQO adapted to support the Entity Framework. That would certainly placate the domain-driven design fans along with those who use db’s other than MS SQL.

Finally, a bit of a rant: I’m kind-of annoyed that PLINQO only has one way to select the tables you want to include in code generation: you have to write a RegEx to identify tables to exclude. I’ve worked on several projects where I want to generate entities for less than 50% of the tables in my database. For instance, when writing modules for DotNetNuke, I only want to generate entities for my 5 tables, not the 100+ tables that come with a DNN installation.

NetTiers had a dialog to select tables for code generation. It sure would be nice to bring that back in PLINQO. If a dialog box is too much trouble, at least there could be a switch to specify whether my RegEx is an include list or an exclude list. I submitted a ticket to CodeSmith on this one. Please vote and add comments on their website if you support this idea. How about it, CodeSmith? 🙂

See the new PLINQO website at http://www.plinqo.com/ for downloads, documentation and an offer to get a free copy of CodeSmith. I also suggest that you watch both introductory videos: Video 1. Video 2.

Kick it on DotNetKicks.com [Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

Welcome

Welcome to my blog.  I’ll be talking about life as a technologist mitigating the IT trifecta between developers, management and technology itself.  It’s an experience being the hub between these factions so I’ll share some of my experiences and tips & tricks as I discover them.  I don’t claim to be an expert in any area (“We don’t know a millionth of one percent about anything.” – Thomas Edison) but I hope that sharing solutions to my trials and tribulations may save you some of the same frustration.