Written by: willgillen 3/2/2007
The past couple of weeks, we've been upgrading some of our customer sites to the latest version of DotNetNuke 4.4.1. The new version offers so many improvements in performance, that it is almost necessary to upgrade to this latest version. However, through the process of upgrading the sites, we have found a few glitches in the packages for the new version of DotNetNuke. Let me tell you about one such event. While upgrading a site from DNN 4.3.7 to 4.4.1, we decided to try out some of the performance options to see how well the differing enhancements improved the speed and reliability of the web portal. One of the features that we tried was changing the default caching mechanism from "FileBasedCachingProvider" to "BroadcastPollingCachingProvider". This is done through changing the defaultProvider option in the corresponding Web.Config setting. However, once we configured this option, the entire website failed to load, and the ONLY thing that DotNetNuke would display was: "A Critical Error has occurred... A Critical Error has occurred..." This was quite disappointing especially since no matter how we tried to kickstart the application it failed to load and always displayed the same error. It was quite unfortunate that there appeared to be no way to even tell what the underlying problem was. Since I couldn't access the DotNetNuke LogViewer to see what the underlying error was, I decided to open a MSSQL Query Analyzer window and attach to the Database. This would allow me to run a query to grab the last 25 Log Events from the Log Viewer in DotNetNuke. I ran the following query:SELECT TOP 25 * FROM eventlog ORDER BY LogCreateDate DESC This query showed me the last 25 log entries, and interestingly they pointed right to the problem. DNN was throwing an exception of (the infamous): "Object reference not set to an instance of an object". But, it also pointed out the stack trace coming from the BroadcastPollingCachingProvider calls. When DNN was trying to load the assembly, it was failing and unable to get an object reference. Lo and Behold, when I looked in the of the DNN \bin folder there was NO Dotnetnuke.Provider.BroadcastPollingProvider.dll to my amazement. I dug around on the DotNetNuke forums and found that there are actually 5 known assemblies missing in the DNN-Upgrade and DNN-Install packages for DotNetNuke 4.4.0 and 4.4.1. The following assemblies are missing inside upgrade and install package: DotNetNuke.ASP2MenuNavigationProvider.dllDotNetNuke.Caching.BroadcastPollingCachingProvider.dllDotNetNuke.Caching.BroadcastPollingCachingProvider.SQLDataProvider.dllDotNetNuke.DNNDropDownNavigationProvider.dllDotNetNuke.DNNMenuNavigationProvider.dllDotNetNuke.DNNTreeNavigationProvider.dll So, if you are planning on upgrading, please make sure you obtain these files from the DNN-Source package and include them in your \bin folder or you could run into trouble. Especially if making changes to the caching provider, or if you use skins with the new ASP3MenuNavigationProvider, or the DNNMenuNavigationProvider. Also, notice that you CAN view the DNN EventLog even if the entire website is down. Don't get frustrated, just keep digging and you'll get your site back online in no time.
The past couple of weeks, we've been upgrading some of our customer sites to the latest version of DotNetNuke 4.4.1. The new version offers so many improvements in performance, that it is almost necessary to upgrade to this latest version.
However, through the process of upgrading the sites, we have found a few glitches in the packages for the new version of DotNetNuke. Let me tell you about one such event.
While upgrading a site from DNN 4.3.7 to 4.4.1, we decided to try out some of the performance options to see how well the differing enhancements improved the speed and reliability of the web portal. One of the features that we tried was changing the default caching mechanism from "FileBasedCachingProvider" to "BroadcastPollingCachingProvider". This is done through changing the defaultProvider option in the corresponding Web.Config setting.
However, once we configured this option, the entire website failed to load, and the ONLY thing that DotNetNuke would display was: "A Critical Error has occurred... A Critical Error has occurred..." This was quite disappointing especially since no matter how we tried to kickstart the application it failed to load and always displayed the same error. It was quite unfortunate that there appeared to be no way to even tell what the underlying problem was.
Since I couldn't access the DotNetNuke LogViewer to see what the underlying error was, I decided to open a MSSQL Query Analyzer window and attach to the Database. This would allow me to run a query to grab the last 25 Log Events from the Log Viewer in DotNetNuke.
I ran the following query:SELECT TOP 25 * FROM eventlog ORDER BY LogCreateDate DESC
This query showed me the last 25 log entries, and interestingly they pointed right to the problem. DNN was throwing an exception of (the infamous): "Object reference not set to an instance of an object". But, it also pointed out the stack trace coming from the BroadcastPollingCachingProvider calls. When DNN was trying to load the assembly, it was failing and unable to get an object reference. Lo and Behold, when I looked in the of the DNN \bin folder there was NO Dotnetnuke.Provider.BroadcastPollingProvider.dll to my amazement.
I dug around on the DotNetNuke forums and found that there are actually 5 known assemblies missing in the DNN-Upgrade and DNN-Install packages for DotNetNuke 4.4.0 and 4.4.1.
The following assemblies are missing inside upgrade and install package:
DotNetNuke.ASP2MenuNavigationProvider.dllDotNetNuke.Caching.BroadcastPollingCachingProvider.dllDotNetNuke.Caching.BroadcastPollingCachingProvider.SQLDataProvider.dllDotNetNuke.DNNDropDownNavigationProvider.dllDotNetNuke.DNNMenuNavigationProvider.dllDotNetNuke.DNNTreeNavigationProvider.dll
So, if you are planning on upgrading, please make sure you obtain these files from the DNN-Source package and include them in your \bin folder or you could run into trouble. Especially if making changes to the caching provider, or if you use skins with the new ASP3MenuNavigationProvider, or the DNNMenuNavigationProvider.
Also, notice that you CAN view the DNN EventLog even if the entire website is down. Don't get frustrated, just keep digging and you'll get your site back online in no time.