I had been working in my development install (DNN 4.8.0) on a major upgrade to a previously released module for several weeks, creating module install packages periodically with Host->Module Definitions -> Create Module Package for testing on a separate install. Because I was having a bit of a problem with targeting .Net 3.5, I decided to upgrade the development install to DNN 4.8.1.  As it was ONLY a minor upgrade to my development install I stupidly did not bother to do a full backup - only database (thankfully) and web.config.  All went well with the upgrade and I went back to work on coding the module upgrade.  I was surprised to notice that several new properties I had added to a class earlier today were no longer there. Further analysis showed that ALL code changes made the past few weeks were gone and that all files in App_Code and in my modules folder under DesktopModules (some 60 files in all) showed a creation date/time matching that of the framework upgrade I had just done.

Here's what happened: In creating install packages periodically using Create Module Package (which places the install zip files in the /Install/Modules/ folder), I had forgotten that one of the earliest install packages was still setting in the module install folder. The framework upgrade triggered the install of this old version replacing ALL of the module files with the old files.

Here's the warning:

1. BACKUP-BACKUP-BACKUP even for what would appear to be minor upgrades.
2. Do not leave module install packages (.zip extension) in the /Install/Modules/ folder. Move them elsewhere as soon as created.  Create Module Package really needs to allow the host to specify a different folder for the destination of the created package.
3. Get into a practice of incrementing module version numbers will still in development.  Because I don't normally increment the version number until the final release, the installer saw both the current module version number and that of the old package as being the same and apparently treated it as a reinstall of the same version allowing the files to be overwritten.
4. BACKUP-BACKUP-BACKUP

Now, to get back to coding . . . while I can recall even half of the changes I had made.

---

Bill, WESNet Designs
Team Lead - DotNetNuke Gallery Module Project (Not Actively Being Developed)
Extensions Forge Projects . . .
Current: UserExport, ContentDeJour, ePrayer, DNN NewsTicker, By Invitation
Coming Soon: FRBO-For Rent By Owner

Sorry to hear about that Bill.

Source control really is the answer and it helps when you want to look at a previous version of code. If you are making an Open Source module http://CodePlex.com is highly recommended.

---

Michael Washington
http://ADefWebserver.com

A Free Open Source DotNetNuke Help Desk Module