Contents tagged with Troubleshooting
-
Why isn’t My Scheduled Task Executing?
A quick diversion from the JavaScript Common Difficulties and Misconceptions series (I have another post queued up, just need to write the sample code), for an issue I just ran into.
Created a scheduled task for DNN, but it’s sitting in the scheduler queue, just getting more and more overdue. Why won’t my task run?
Somehow I missed the constructor from the tasks I copied. Your task needs a constructor that takes a
ScheduleHistoryItem
to run via the scheduler. -
Compile Error Message HTML
Server Error in '/dotnetnuke_2' Application.
Compilation Error
Description: An error occurred during the compilation of a resource required to service this request. Please review the following specific error details and modify your source code appropriately.
Compiler Error Message: BC30451: Name 'Initialize' is not declared.
Source Error:
Line 81:
Line 82: ' stop scheduled jobs
Line 83: Initialize.Init(app)
Line 84:
Line 85: ' log APPLICATION_END event
Source File: C:\Inetpub\wwwroot\DotNetNuke\Website\App_Code\Global.asax.vb Line: 89
Show Detailed Compiler Output:Show Complete Compilation Source:
Version Information: Microsoft .NET Framework Version:2.0.50727.1433; ASP.NET Version:2.0.50727.1433
-
Get Module by Module ID in DotNetNuke
When building [DotNetNuke] modules, a number of times I've run up against the issue of trying to instantiate a ModuleInfo instance with only a module ID. However, the GetModule signature on ModuleController takes both a module ID and a tab ID. In this latest instance where I've come against this issue, I was actually trying to get a tab ID based on the module ID, so I obviously didn't already have one to provide.
As I started to move down the road of writing my own query to get this simple thing done, I found that the GetModule method and underlying query will take a "null" value for the tab ID! Unbeknownst to me, the solution was right in front of me, right where I expected it to be the whole time, I just couldn't see it.
So, if you need a ModuleInfo instance and you only have a module ID, call GetModule(moduleId, Null.NullInteger) and you're good to go!
(I've put in a request with the people in charge to add an overload to GetModule so that this is more obvious going forward)
-
Check your CSS for DotNetNuke 4.9.0
I started on an update to one of our modules for [DotNetNuke] this week, and was surprised to see many of the administrative pages looked like they had no styles applied to them. Tables were jumbled, with no differentiation between header and or row content; things just didn’t look right.
As I tried to adjust some of those styles, I came to realize that the issue was, in fact, a change in the behavior of [DNN]. While before, when I accessed a control in the admin directory of my module, the module.css file in that directory was referenced; now the module.css in the main folder of my module was referenced (that is, previously DesktopModules/MyModule/admin/module.css was referenced, but now /DesktopModules/MyModule/module.css is referenced).
After some digging, I figured out that the change happened in [DNN] 4.9.0 (the latest version) and found mention of it in [DotNetNuke]'s Issue Tracker. So, now, the moral of this story. Starting in [DotNetNuke] version 4.9.0, only the module.css in the main folder of a module is referenced, regardless of where the control being loaded lives (unless there isn't a module.css there). Therefore, you only need one module.css to control the styles of all of your controls. This is great news from a maintainability standpoint.
However, if your modules still need to support versions before 4.9.0, we need to figure out how to manage this relationship. It seems obvious that, to support 4.9.0, we need to combine all of our stylesheets from whatever folders they may be in currently, creating one stylesheet for all our controls in our module’s root folder (I used CleanCss to combine them and remove duplicate styles).
Now, after the obvious choice, we have to face the less-obvious choice of how to provide those same styles on pre-4.9.0 sites. My first instinct was to remove all content from the module.css in my admin folder, and replace it with an import to the main module.css, that is
@import url('../module.css')
. This may work, but I wasn’t sure if the browser would cache that reference, and it seemed wrong to have to load two files just to get to the real one. What I ended up deciding was to create a Post-Build Event in my project to copy module.css from my module’s root folder into the admin folder (which looks likecopy $(ProjectDir)module.css $(ProjectDir)admin/module.css
).Hopefully this provides you module developers with a good guideline for what’s going on and how to deal with it when you come across your modules acting like they’ve never heard of this “stylesheet” you keep telling them about.
-
DotNetNuke Gotcha: Upgrading DotNetNuke Modules
I was recently tasked with investigating a mysterious error on a customer's site, which I finally tracked down to an oversight in the upgrade process of a [DotNetNuke] module. The error threw up a YSOD, (though in later testing on a different site, it also showed up in a regular [DNN] red triangle error message), with an error message like "Multiple controls with the same ID 'ctr376' were found. FindControl requires that controls have unique IDs." Talking it through with Chris, we figured out that there were two entries in this module definition for the same control key. So, when we tried to go to the Edit control, [DNN] was attempting to load two different .ascx controls in the Admin control, which caused the whole thing to kind of blow up and die.
So, how did we get two controls registered for the same control key? The answer was obvious enough, probably because it's bit me before: upgrades. When you upgrade a module in [DNN], the installer adds any new control definitions that it finds in your module's manifest file. It doesn't, however, remove control definitions that it doesn't find any more. This means that if you rename a ControlKey, or, as in this case, you rename a control itself, you'll have duplicate entries pointing to incorrect information. Most of the time this isn't too much of an issue, but sometimes it'll cause mysterious errors that take up your morning before you figure them out.
The solution: Be aware when you are renaming or removing any entries from your module's manifest. When you find yourself renaming, make sure that you add a line to that version's SQL script to remove the old entry from the database. At the very least this keeps your module definition clean, and it also avoids nasty, hard-to-track-down bugs. This would look something like
DELETE databaseOwner.[objectQualifier_ModuleControls]
WHERE ControlKey = 'Edit'
AND ControlSrc = 'DesktopModules/EngageSample/Edit.ascx'
One other note, if you rename or remove a control from your module, there's also a mechanism to have those removed from the site upon upgrade. If you add a text file with the name of the version to your module (and to your manifest's files section), [DNN] will look for any files listed in that file, and delete them if it finds them. For example, if I rename Edit.ascx to EditSample.ascx in version 02.02.05 of a module, I can add 02.02.05.txt to the module package and manifest. This file would contain one line, "DesktopModules/EngageSample/Edit.ascx" and I could add additional lines for other files, including files in the bin folder, if I needed to. Upon uploading the new 02.02.05 module package, no more Edit.ascx.
These two techniques, applied together, can help keep your module nice and tidy as you upgrade, and keep all of those mysterious, day-stealing errors away.
Hope it helps!
[Cross posted from http://www.engagesoftware.com/Blog/EntryID/161.aspx]
-
DotNetNuke Site Compile Error: "BC30451: Name 'Initialize' is not declared."
Today was at least the second time that I had seen the above error happen on my local development [DNN] site. I don't know what happened, maybe I accidentally recompiled the source with something strange in there (though the date on the assembly didn't seem to indicate that), but replacing DotNetNuke.dll in my bin folder with a fresh copy made it go away. Hopefully this'll help someone else out in the same situation.*UPDATE*: I later realized that I had compiled a project with references to an earlier version DotNetNuke, and those references were set to Copy Local. Moral of the story: make sure you're running what you think you're running.