DotNetNuke

Error Installing Module(s) on DNN 4.5.5 at WebHost4Life

John Watson — Thu, 23 Aug 2007 04:27:47 GMT

I was setting up a new DNN installation at WH4L and received this error while running the installation wizard. I first tried manually cleaning things out and doing it again only to receive the same error. Turns out the trick is the file permissions on the newly installed modules under \DesktopModules aren't correct. When you receive the errors, simply open a new browser window, login to WH4L control panel, go to Security | File Permission and reset permissions for NETWORK SERVICE with the box check for subfolders. When that's finished, switch back to the installer wizard with the errors still showing and you can now click Next to continue and finish the installation.

Successful upgrade of DNN v3 to v4

John Watson — Sun, 24 Sep 2006 22:55:00 GMT

This weekend I upgraded our hosted church site to the current release of DotNetNuke v4.3.5. Here's a quick summary of the steps I took and some observations.

Steps to upgrade:

Unzip the install package to a local directory.
Copy release.config to web.config in the install root directory (local machine).
Update the web.config: replace machine key with ours; comment out the SQL Express connection strings and uncomment the SQL standard strings; put in correct connecting string settings for the hosted site; uncomment trust level and change Medium to Full*; remove databaseOwner prefix.
Backup hosted site to local machine using ftp client.
Backup hosted database.
Remove all files from root directory of hosted site.
Remove all subdirectories except /Portals/0 which contains our site stuff.
Ftp the site from local machine to hosted site.
Switch the hosted site from ASP.NET 1.1 to 2.0
Hit the hosted site for the first time - triggering an upgrade.

* Learned this after the fact - modules will not install since they're compiled on the fly and the zips are removed from the Install/Modules subdirectory. Full trust is needed to allow the ASP.NET application permission to read/load/delete the modules zips.

One observation I noticed is with User Defined Tables. I have several with a date column in them. In V4, UDTs have been enhanced to support Date, Time, and Timestamp types. For whatever the reason, the decision was made to upgrade an old Date datatype to a Timestamp and the time portion defaults to 12:00:00. Why they chose to do this is beyond me. If all we had was a date before, why not keep the datatype as Date. Perhaps it's because the old Date datatype was in actuality a full timestamp. For me, it meant going in to edit the UDT settings for dozens of tables to switch from Timestamp to Date.

DNN upgrade and the infamous Could not load type 'DotNetNuke.Common.Global'

John Watson — Thu, 21 Sep 2006 12:42:00 GMT

I manage a DNN site which is currently running on DNN 3.1.1 hosted at WebHost4Life. I have a local backup of the site on my home server running on Win2003 and SQL 2005. I tried to upgrade the local copy to the current release 4.3.5 using the xxx_Install.zip and on the first try I received the infamous "Could not load type 'DotNetNuke.Common.Global'" error. I'm referring to it as infamous because there are a lot of howls posted over at the DNN forums site with very few real suggestions of getting around the problem.

To test the upgrade, I backed up my copy of web.config, used the development.config as a starting point, and put the correct SQL provider settings in. I used a diff tool to copy directly from the xxx_Install.zip to the website folder - replacing everything, removing what wasn't there any more and skipping the *.vb source files. When I first hit the site, I received the could not load type error. After hunting around on the web and finding little or no helpful information (such as this thread), I began trying to diagnose it myself.

Judging by the initial quick error, I figured it was something very basic with the configuration. However, I noticed in the event log details on the server that it seemed to be getting past default.aspx and was down in /install/install.aspx when it died. Hmm...remembering that all the modules are in zips now and get automagically deployed, I tried something whimsical - deleting all the zips (maybe it was trying to load these?) and voila - it got further along.

At this point, I tried a couple of things in quick succession (it was getting late last night). First, uncomment the enable medium trust - the problem w/ non-colorizing IDEs such as Notepad is that comment markers are easy to miss. Second, I got a different error about missing a *.vb file. I recalled some discussions over on ScottGu's blog about the compilation model being different under 2.0 so on a whim I went back to the xxx_Install.zip and copied over all the *.vb files. Note, this is my "pseudo-production" server - I purposely did not install VS.NET to avoid the usual issues of "it works on my development machine". After that, the site came up minus the custom modules and the skins.

It's a start at least and I think I've stumbled onto something regarding what is going on during an upgrade. Unfortunately, I don't really have the time or luxury of building/rebuilding this to test/diagnose the issue further. I'm a big fan of cookbook-style guides so maybe I'll get to one soon. I hope to finish my testing/eval and get the site pushed out to the hosting company by the weekend. Also, this just shows me that I've got to spend some dedicated time working with 2.0, heck 3.0 is already starting to pop up!

DNN Error "Invalid attempt to read when no data is present"

John Watson — Mon, 10 Jul 2006 23:01:00 GMT

When upgrading from 4.3.1 to 4.3.2 I encountered the above error. A few posts in the DNN Forums suggested there were problems with the portals defined. In my case, I had one portal defined with id of zero (0) yet there was also a portal id one (1) called “My Website” with most other columns null. I started the 4.x journey with 4.0.2 and checking there I found only one row in Portals. So....perhaps the upgrade to 4.3.1 did something? Anyway, I had just tried my cookbook approach to upgrading posted about here so I simply deleted the database, recopied, fixed the aliases then deleted the spurious row. When I first hit the site it ran through the upgrade perfectly then I clicked the link at the bottom of the upgrade report page and was “in like Flynn”.

How to upgrade a DNN site

John Watson — Mon, 10 Jul 2006 22:39:00 GMT

I've got a pretty simple “cookbook” way to upgrade (or test upgrade) a DNN site which I thought I'd share. I'm using 4.x which means SQL Server 2005 and VS.NET 2005.

Unzip the download to a new directory
Make the new directory a virtual web share
Copy/paste either development.config or release.config and rename to web.config
Compare the old web.config to the new web.config (using a tool like WinMerge) and copy over the database connection string (edit to use new database name from step #5) and machine key.
Copy the database - while only SQL Server needs to be running to use the site, to take advantage of the new copy database feature you must have SQL Server Agent and SQL Server Integration Services running.
Open the Portal Alias table and fix up the URLs to match the new directory setup in step #2.
Fire up a browser and hit the new URL - upgrade should kick off automatically and leave you with a link to the home page.

Now go cut the grass or whatever chores you've been putting off.