I had a strange error reported to me by someone who had upgraded to their website.  The exception was deep down the call stack in the NavigateUrl() call, which is used to generate a Url given a TabId and some query string parameters.

The exception turned out to be a null reference returned by 'PortalController.GetCurrentPortalSettings'.  Now this call just looks up the Context.ApplicationInstance.Items dictionary and returns the stored PortalSettings.   The UrlRewriter module is responsible for figuring out the current portal of each request received by the DNN framework, and then stashing the PortalSettings object into the App context.

Now, because the component (which has worked without problem since 4.0) is a HttpHandler, and ends in .axd, there is a new section in the Url Rewriter code, which looks like this:

'exit if a request for a .net mapping that isn't a content page is made i.e. axd
If Request.Url.LocalPath.ToLower.EndsWith(".aspx") = False _
AndAlso Request.Url.LocalPath.ToLower.EndsWith(".asmx") = False _
AndAlso Request.Url.LocalPath.ToLower.EndsWith(".ashx") = False Then
   Exit Sub
End If

Now, this code throws out any request from the Url Rewriter which isn't an .aspx, .asmx or .aspx.

I'm not sure why it was inserted, but I think it was a mistake to exit processing before the current portal could be identified and set in the application context - my Http Handler must not be the only one written for DNN that relies on calling core code with a dependency on the 'CurrentPortalSettings' to be a valid reference.

I think a better idea would have been an extension regex filter, so that different requests could be filtered - so that, for instance, I could have modified the web.config to allow requests through to my specific Http handler, rather than a blanket ban on *all* handlers which have an extension of .axd. So while my requested Http Handler would not go through the rewriting code, it could at least run through the piece of code which identifies the current portal/portal alias based on the requesting Url.

It's not a big issue, but I think some others are bound to trip up on this particular hurdle.