A few months ago, we upgraded a client’s development and production sites from DNN 6 to DNN 7.3. Other than a few minor issues, the upgrades went well and the sites have been running very well.
Recently, we started encountering an issue when trying to access the Add Modules dialog in the control bar.
Using Firebug I could see that an HTTP 500 error was being returned from a call to GetPortalDesktopModules. Digging in further, the error was occurring when attempting to access an internal service URL:
After trying out numerous “fixes” I started thinking about what was different between the two sites since this was only occurring in the development site.
The majority of the client’s modules are all App_Code style modules and I had recently converted one of them to a web application. This web application version was installed side by side with the existing module (it was not removed so we could compare and test). I tried to keep the majority of what already existed in place. Including the module’s definition/information.
That was the only clue I needed.
I looked at the DNN source code and saw that the GetPortalDesktopModules method was retrieving information from the DesktopModules table in the database and storing the results in a key value pair collection.
In the DesktopModules table the module I had recently converted and the recently converted module had the same FriendlyName. I changed one of the values and the Add Modules dialog loaded!
To sum it all up:
If your Add Modules dialog never loads and endlessly displays “Loading Module(s)”, take a look in your DesktopModules table for duplicate FriendlyName values. If duplicates are found, change one of the values, clear the site’s cache, and open up the Add Modules dialog.