Sunday, September 24, 2006

Successful upgrade of DotNetNuke (DNN) v3 to v4

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:

  1. Unzip the install package to a local directory.
  2. Copy release.config to web.config in the install root directory (local machine).
  3. 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.
  4. Backup hosted site to local machine using ftp client.
  5. Backup hosted database.
  6. Remove all files from root directory of hosted site.
  7. Remove all subdirectories except /Portals/0 which contains our site stuff.
  8. Ftp the site from local machine to hosted site.
  9. Switch the hosted site from ASP.NET 1.1 to 2.0
  10. 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.

Original post

No comments:

Post a Comment