DotNetNuke.Entities.Portals.PortalSettings..ctor(Int32 tabID, PortalAliasInfo objPortalAliasInfo) DNN 05.06.00

The Problem

After updating a DNN site from 05.01.01 to DNN 05.06.00 we received the following error.

image

——————————————————————————–

Object reference not set to an instance of an object.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.NullReferenceException: Object reference not set to an instance of an object.

Source Error:

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below. 

Stack Trace:

[NullReferenceException: Object reference not set to an instance of an object.]
   DotNetNuke.Entities.Portals.PortalSettings..ctor(Int32 tabID, PortalAliasInfo objPortalAliasInfo) +49
   DotNetNuke.HttpModules.UrlRewriteModule.OnBeginRequest(Object s, EventArgs e) +2087
   System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +68
   System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +75

 

We found that this is a bit of a reported issue with DNN websites that have been upgraded to DNN 05.06.00. There is a bit of chatter about it here:
http://www.dotnetnuke.com/Resources/Forums/tabid/795/forumid/200/threadid/396504/scope/posts/Default.aspx

Basically the problem is that if you access a page like

http://domain.com/AboutUs/History/tabid/108/Default.aspx The site will work.

but if you access http://www.domain.com  it fails.

There is a lot of heads spinning on this one, talk about the HTTP handler and there is no doubt in our mind that much is not right with the DNN 05.06.00 release. Actually this release has probably caused us the most headaches for our modules in the last few years.

The Fix

imageWe found the fix for this problem is easy. Set the IIS Application Pool that relates to the site’s managed pipeline to “Integrated” from “classic”.

In IIS 7

it looks a little like that.

This should fix this particular bug in a few seconds.

crtsrv HTTP Error 500.19 – Internal Server Error 64 Bit Windows 2008

When accessing the newly configured /CRTSRV service on a windows 2008 server, we were thrown the following error.

HTTP Error 500.19 – Internal Server Error
The requested page cannot be accessed because the related configuration data for the page is invalid.

Module CustomErrorModule
Notification SendResponse
Handler Not yet determined
Error Code 0x80070003
Config Error Cannot read configuration file 
Config File \\?\C:\Windows\system32\CertSrv\en-US\web.config
Requested URL
http://localhost:80/certsrv/certfnsh.asp
Physical Path C:\Windows\system32\CertSrv\en-US\certfnsh.asp
Logon Method Not yet determined
Logon User Not yet determined

Browsing to the directory showed that:

Config File \\?\C:\Windows\system32\CertSrv\en-US\web.config

File is missing or does not exist.

This was somewhat frustrating because it was a fresh instance of Windows 2008 server and the service had just been added and configured without error.

The long and short of it all for us was that it related to the fact that the server was a 64 bit server, and in IIS by default, 32 bit applications are enabled.

To fix the problem we started IIS.

Browsed to the Application Pools and ensured that the application pool for the CRTSRV service had “Enable 32-Bit Applications” set to False

image

This made the site come alive!

(Can’t help but comment how sucky it is that this does not just work out of the box. Even if I cut MS some slack and acknowledge how many variables are in place for this type of configuration, it still SUCKS that the status error code thrown is as good as meaningless! – This is why I hate MS more and more every day!)