From the Desk of Brandon Haynes

Some time ago, I wrote about an approach for enabling ASP.NET 2.0 localization within a DotNetNuke application.  This approach not only required a core modification, but the change introduced a potential breaking change with third party modules.  This was clearly unsatisfactory, and the fact that I was unable to fully solve the problem has been vexing me for some time.

As my research on the recently-released Linq to Sql Adapter (currently hosted on CodePlex) wound down, I decided to investigate a new approach to solving the problem.  In my opinion, an optimal solution would fulfill the following requirements:

1. Require no core changes
2. Be side-by-side compatible with the existing DotNetNuke localization services
3. Require little configuration by a hosting user
4. Allow strongly-typed per-portal and per-culture access to existing global DotNetNuke resources
5. Minimal additional in-memory footprint and reasonable performance
6. Enable use of the meta:resourcekey attribute in DotNetNuke modules
7. Be fully compatibility with third-party modules

I am pleased to announce a preview release of a custom BuildProvider that, to my knowledge, accomplishes all of these goals.

In a previous entry, I discussed a potential solution to a longstanding problem.  The DotNetNuke CMS framework allows declaration of an object qualifier and database owner on a per-installation basis.  This effectively varies the fully-qualified database entity names at runtime.  Because the Linq to Sql system by default utilizes a class attribution approach, it does not lend itself well to such runtime adaptation.

Here I describe the steps necessary to use Linq to Sql within a DotNetNuke module in a reliable, distributable manner.

The .NET-supplied DataContext allows Linq to Sql development using the attributed model automatically generated by a Visual Studio designer. However, when deployed within DotNetNuke, these attributes do not pick up the database owner and object qualfier required by DotNetNuke.  Because of this, large-scale deployment of modules using Linq to Sql is infesable, and modules using the technology are unfortunately limited to internal applications.

To rememdy this issue, I have developed an adapter that converts the attributed meta model generated by the designer into a DotNetNuke-compatable model that uses both the object qualifier and database owner specified by an end-installation. 

One of my (few) cavils about the DotNetNuke Content Management System is the organization of the administrator menu.  Presenting an administrator with thirteen options (including somewhat inscrutable choices like “Extensions” and “Solutions”), is easily overwhelming for an often-technically unsophisticated administrator.  Indeed, both feedback from users and log analysis have indicated that several of these options are rarely utilized and thereby serve only to clutter the interface and increase the learning curve.

In pre-5.0 versions, despite being persisted to the database like any other page, the admin menu is restricted to one level.  This was a hardcoded limitation; though one could change the verbiage, order, or visibility of the items in the menu, one could not introduce additional levels of organization (without several changes to the core framework).

With DotNetNuke 5.0, however, because administrator pages are treated on-par with any other page on a site, an improvement in organization becomes possible.  Herein I discuss the changes necessary to, in my opinion, improve the overall organization of the DotNetNuke administrator menu.

I recently encountered an issue with the SSRS ReportViewer control where the parameter drop-down list was of insufficient width for the parameters contained therein.  Surprisingly, a search yielded no solutions.  Indeed, several individuals indicated that changing this width was not possible.

Fortunately, it does turn out to be possible.

Please bear with me while I move content from my previous blog site, located at brandonhaynes.org.  Content and links may be of inconsistent quality until such a time as I have fully reconstituted the site.

B

I recently wrote about the use of debug-build assemblies to identify and correct difficult–to-diagnose problems with a DotNetNuke installation (see this for a detailed discussion).

To date, a number of people have successfully used these builds in correcting a number of relatively arcane problems.  As such, I have elected to deploy debug-build version of the core DNN assemblies for the recently-released 4.9 version.

I recently wrote about implementing a custom PageFlow navigation provider in the WCSF library.  Since then, the patterns team has broken out the PageFlow block into a separate package (formally the “Patterns & Practices: Web Client Software Factory Contrib“).

Since my existing PageFlow navigation provider-related modifications became obsolete with this change, I thought I’d spend a few minutes porting my changes to the new block.  I actually completed this task a couple of months ago, but have just now found the time to post it publicly.  Thanks to those who persevered in prodding me to put it online!

In my previous post, I discussed my reasons and motivations behind providing DotNetNuke assemblies with debug symbols to the general public.  Herein, visitors will find links to those files and instructions for generating a call stack with file names and line numbers.

Instructions for using debug assemblies

1. Back up your entire DotNetNuke installation, including ALL files and databases.  You will especially need copies of your core production assemblies, because they will need to be restored after debugging is complete.  I recommend executing these steps on a non-production machine.
2. By downloading any files from this site, you must agree to the following (in addition to any subsequent licensing agreements below):

THIS SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

1. Download relevant files below, and copy them into the bin directory of your DotNetNuke installation (i.e.; if you are having trouble with httpModule functionality, you need only to download DotNetNuke.HttpModules.dll).
2. Navigate to your DotNetNuke site, and reproduce the error.
3. Locate the relevant exception in your event viewer (while logged in as an Administrator, select Admin->Event Viewer and click on the most recent exception).
4. Ensure that you’re actually generating a call stack with filenames and line numbers (see below: How do I know if it worked?)
5. Copy and paste this exception, along with background information, into your request for help on the DotNetNuke forums.
6. Restore your backed-up assemblies over the assemblies you downloaded here.  This is important — debug builds are significantly slower than their production counterparts.  You may optionally choose to remove the .pdb files; they are not required for release functionality, and are ignored.
7. Navigate to your website and ensure continued functionality.

Downloads

DotNetNuke licensing guidelines require that I provide the following verbiage.  Note that downloading any of the assemblies provided below indicates binding consent to these terms. 

DotNetNuke is provided free, as open-source software, and licensed under a BSD-style agreement.  The licensing agreement reads as follows: 

DotNetNuke® – http://www.dotnetnuke.com
Copyright (C) 2002-2008
by DotNetNuke Corporation

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Debug-build assemblies:

• DotNetNuke.dll (5.0.1)
• DotNetNuke.HttpModules.dll (5.0.1)
• DotNetNuke.dll (4.9.2)
• DotNetNuke.HttpModules.dll (4.9.2)
• DotNetNuke.dll(4.9)
• DotNetNuke.HttpModules.dll (4.9)
• DotNetNuke.dll (4.8.4)
• DotNetNuke.HttpModules.dll (4.8.4)

How do I know if it worked?

Call stacks involving assemblies with debug information will read similar to the following:

System.Net.Mail.SmtpException: The operation has timed out. at System.Net.Mail.SmtpClient.Send(MailMessage message) at DotNetNuke.Services.Mail.Mail.SendMail(String MailFrom, String MailTo, String Cc, String Bcc, String ReplyTo, MailPriority Priority, String Subject, MailFormat BodyFormat, Encoding BodyEncoding, String Body, String[] Attachment, String SMTPServer, String SMTPAuthentication, String SMTPUsername, String SMTPPassword, Boolean SMTPEnableSSL) in C:\…\DotNetNuke\Library\Components\Mail\Mail.vb:line 315

Note that the filename(s) and line number(s) (highlighted above) are present in the call stack.  This additional information is what you are looking to provide to those assisting.

Final Words

I have tested this procedure on a local DotNetNuke deployment, and it appears to work correctly.  However, I would appreciate feedback from those using this method in the wild, and especially how I might clarify the instructions to be more accessible to less experienced users and developers.

I hope this helps those out there with difficult-to-diagnose DotNetNuke issues!

B

During my time working with DotNetNuke, I have encountered innumerable forum posts in the following general form:

I’m getting a very vague general exception error, and I’m not sure what is causing it.  There doesn’t seem to be anything visible in the application . . . [and] no errors as I’m navigating the site. Any and all help is greatly appreciated!

StackTrace: [NullReferenceException: Object reference not set to an instance of an object.]
   DotNetNuke.UI.Skins.SkinDefaults..ctor(SkinDefaultType DefaultType) +189
   DotNetNuke .Common.Globals.get_DefaultSkin() +31
   DotNetNuke.Entities.Portals.PortalSettings.GetPortalSettings(Int32 TabId, PortalAliasInfo objPortalAliasInfo) +2797
   DotNetNuke.Entities.Portals.PortalSettings..ctor(Int32 tabId, PortalAliasInfo objPortalAliasInfo) +82
   DotNetNuke.HttpModules.UrlRewriteModule.OnBeginRequest(Object s, EventArgs e) +3303
   System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +92
   System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +64

Experienced DNN developers will recognize the general area in which the error is occurring (missing skinningDefaults in DotNetNuke.config) and probably some general guidance to rectify the error (check that DotNetNuke.config exists, and correctly contains the proper skinningDefaults element).

This is fine for exceptions that occur frequently, but how does an experienced developer guide a novice in finding a solution to this issue?

[NullReferenceException: Object reference not set to an instance of an object.]
   DotNetNuke.HttpModules.UrlRewriteModule.RewriteUrl(HttpApplication app) +378
   DotNetNuke.HttpModules.UrlRewriteModule.OnBeginRequest(Object s, EventArgs e) +1180
   System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +92
   System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +64

Even a sophisticated developer would need to explore several avenues in finding a solution.  Assisting a relatively novice forum user in performing these tasks is problematic — such assistance would require a number of back-and-forth exchanges.  With regret, I unfortunately observe many problems go unremedied for this reason (as, to date, is the exception posted immediately above).