From the Desk of Brandon Haynes

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.

(more…)

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!

(more…)

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). (more…)

For those that are not familiar with the UpmMembershipProvider membership provider, it is a part of Microsoft’s Commerce Server 2007 product, and is the only provider that offers interoperability with Commerce Server.  It replaces the older AuthManager functionality from Commerce Server 2002.  More importantly, it provides an implementation of the System.Web.Membership.MembershipProvider class, and may thus be used in any ASP.NET application that utilizes the standard membership system.  Read more about the UpmMembershipProvider in Microsoft’s MSDN documentation.

DotNetNuke (DNN) is one such application that uses the ASP.NET membership system.  Because I’ve been working so much with it lately, I decided to investigate whether these two strangers might be successfully introduced — and indeed they can.  Google tells me that I am the only person to date who has successfully accomplished this task (not that surprising, given its relatively esoteric nature).

It turns out that this integration consists of three tasks: (1) configuring Commerce Server appropriately, (2) the routine tasks that one would expect in using the new provider, (3) and a small integration gotcha.  Herein I address these in order. (more…)

Editor’s note: This approach has been obsoleted in favor of the more straightforward, core-friendly ASP.NET 2.0 Localization approach outlined here.

DotNetNuke provided rich localization support (in the DotNetNuke.Services.Localization namespace) long before ASP.NET caught up in version 2.0. Indeed, the core DotNetNuke libraries and UI continue to heavily rely upon this custom implementation to this day.

However, after ASP.NET 2.0 was released, there were apparently a number of issues revolving around the new localization, backwards compatibility, and the existing DotNetNuke localization. As a result, the core team chose to disable all ASP.NET 2.0 localization at the application level and to rely exclusively upon its internal implementation. This is unfortunate, but understandable — the core team has a lot of audiences, and must balance the act of pleasing them all.

DotNetNuke localization is excellent, and for almost every scenario, I strongly recommend using this API.  However, there do exist some niche circumstances that lend toward using ASP.NET 2.0 localization.
Fortunately, with a few small changes, it is possible to restore limited ASP.NET 2.0 functionality to your DotNetNuke installation. Herein I discuss these changes and their system-wide impact.

Before I begin, all the usual warnings apply: back up your data, attempt this only on a development machine, thoroughly test before entering production, et cetera, et cetera. Caveat lector!

With that, let’s get started. (more…)

In installing Microsoft Dynamics CRM 4.0, I ran across a couple of installation issues. These were mostly circumventable, but I thought I’d aggregate them here in case anyone out there has similar problems:

1. The installer created a CRM website, but failed to configure it as an application. I have a very specific server configuration, so this may have caused the problem. Nonetheless, I had to visit IIS and configure my CRM website as its own application and enable Windows Authentication. I believe it was also necessary to configure default.aspx as a default document as well.
2. It was a requirement that the system be exposed via a single SSL port, and this caused some headaches. Obviously, I had to configure the SSL port in IIS. Because this port was different than the non-SSL port configured at installation, there were some registry and database changes required. Specifically:
   1. Under HKLM\Software\Microsoft\MSCRM, the ServerUrl key needs to be updated.
   2. In the DeploymentProperties table of the MSCRM_CONFIG database, the rows with ColumnName in {’AsyncSdkRootDomain’, ‘ADSdkRootDomain’, ‘ADWebApplicationRootDomain’, and ‘ADRootDomainScheme’} need to be updated. The column to update is NVarCharColumn. Value is of the format ’server:port’ (e.g.; ‘microsoft.com:5556′). If running under SSL, you’ll need to update the last key, ADRootDomainScheme, to ‘https’ (also using the NVarCharColumn column).
3. Once I had executed the above changes, the client tool still complained about being able to connect to the server. Using Fiddler, I was able to determine that there was an authentication problem. Modifying the registry keys under HKCU\Software\Microsoft\MSCRMClient did the trick. Apparently the organization was appended to the web application directories, which resulted in a 404 upon connection. I modified WebAppUrl and IntranetServerUrl, but I recommend reviewing all the keys.
4. Apparently the client requires anonymous access to be enabled on the _imgs subdirectory of the CRM installation. This corrected my final authentication issue. Thanks to the poster here for this solution.
5. Finally, after the client installed and connected properly, I received an error when loading outlook which read “An error occurred loading Microsoft Dynamics CRM functionality.” This was apparently due to a conflict between an old 3.0 installation and the 4.0 software. 3.0 failed to fully clean up after itself. Manually removing the duplicate CRM menu did the trick; I used View->Toolbars->Customize, right clicked on the depreciated 3.0 menu, and selected Delete. Restarted Outlook and I was up and running.

That’s a lot of work to get things up and running, but FAR less of a hassle than I experienced in tinkering with the 3.0 version.

B

I was dismayed to discover that one could not configure a custom INavigationService at the web.config level.  As part of my experiments to integrate PageFlow into a DotNetNuke module, I needed such customization, and wanted to continue to configure the providers in the web.config.

So, instead of kludging and compiling my own custom PageFlow libraries, I decided to modify the framework itself and allow customization of the INavigationService at the web.config level.  Required only a small number of code changes, and ultimately the navigation service interface is configured as:

I created a work item in the WSCF project which discusses my changes in a little more detail.  It essentially boiled down to adding a new string attribute (NavigationType) to the provider section class (defaulting to the existing Microsoft.Practices.PageFlow.Services.NavigationService), modifying the BuildProvider method to use this configuration value, and adding the extra parameter to the provider constructor.

Work item is located here.
Patch is located here.

Hope this helps anyone who needs a custom navigation service for the PageFlow block in the WCSF.  I’ll be continuing to blog about my attempts to integrate this block into a DNN module and  have it play nicely with the DNN framework.

B