Can anyone help me. I have 3.0.13 working just fine and downloaded 3.2 to 'upgrade'. What the heck am I supposed to do with the contents of this zip file? It isn't in Nurse's installation docs (unless it is somehow implied).  They don't expect me to overwrite my portals folder, do they? (do I need to know some kind of secret handshake?).  Thanks much in advance.

please refer to the documentation. Theres a file called "DotNetNuke Installation Guide.doc" that describes doing an upgrade on 11-12.

Cathal

Cathal, Thanks for responding, but this is exactly my point. I have been through that documentation front-to-back. The author of this documentation is Charles Nurse. I realize it is difficult to write documentation when you are intimately familiar with a product, so I'm not knocking the effort.

What get's to me is that in many of these threads there is a constant referral to this documentation, and the information simply isn't there. I challenge you to refer me to where it tells me what to do with the zip file on an upgrade. The information on the clean install vs. the upgrade is confused at best, and almost all of it deals with a clean upgrade.

So, what do I do with this zip file on any upgrade? Does anyone know? Is it written down anywhere?

If you can tell me, here is what I will do in return. I will document the procedure from the standpoint of an 'outsider' and send the suggestions to Mr. Nurse.

Thanks.   - Dan

I'm with Dan on this one. After taking nearly a month to get DNN installed at my host I now find 3.1.1 has to be upgraded to 3.2.0. I've no problem in doing this and would want to do it early before I build too much content in the 3.1.1 and then lose it all in an upgrade.

So I downloaded and extracted 3.2.0 and in the documentation folder find the read me which has the following info which raises questions - which I've put in angle brackets...

Application Upgrades

- make sure you always backup your files/database before upgrading to a new version <Does this mean simply FTP my web site locally? If all goes wrong can I simply upload the FTP'd image of my site and it will be back to normal?  How is a site shut down cleanly so that no users are logged in before I do the backup? Is this relevant to the hosted files or only to the database?  With regards database backup which are the critical files? Or all they all critical? As many sites are hosted on remote SQL servers it isn't possible to use SQL backup statements, instead data has to be copied. How is the site shut down cleanly in a consistent state so that all data can be copied? - perhaps a SQL specific question, but on that DNN could describe>

- unzip the code over top of your existing application <I read this as it states, simply unzip the files and FTP them to the host. Is it that simple? What should I be aware of with regards to active users on the site. Sometimes FTP is flaky and times out, is there any file which is the trigger file that should be uploaded last?>

- BACKUP web.config (web.backup.resources) <I can do this ;-) >

- follow procedure in Installation Guide to ensure web.config is set up right <The crux of the problem. I too have read the documentation from cover to cover. The documentation is more along the lines of telling us what something is rather than what it does, its importance and dependencies and what we should / shouldn't be doing with it.  I followed the following:
Upgrade Process

The Upgrade process is similar, except that not as much happens.

The AutoUpgrade function will detect that the Database is different.  If the “AutoUpgrade” setting is set to false then an “Under Construction” will indicate that the site is not available. The administrator can then trigger the Install by using the url – “Install/Install.aspx?mode =Upgrade”.

If ‘AutoUpgrade” is set to true then the Upgrade process starts automatically, providing feedback similar to the following.>

- browse to localhost/DotNetNuke in your web browser <This is on a local machine, what about in a hosted environment?>

- the application will automatically execute the necessary database scripts <As above, how is this managed on a live hosted server?>

However, after following the instructions my installation IS NOW BROKE. The home URL now reverts to:
http://www.mydata.co.uk/Default.aspx?tabid=36&error=Object+reference+not+set+to+an+instance+of+an+object.&content=0

And I get a page saying "An error has occurred" twice.

So I'm broke again.  AAAAARRRRRGGGGGHHH - DNN looks like a great product but I've had nothing but issues for two months on and off. And I *do* have a background in IT development and large scale systems architecture - this isn't new stuff to me.

 

Gents, I hear what you're saying and sympathise. We're caught between a bit of a rock and a hard place on this one, as to write documentation that dealt with every permutation we'd end up with a massive document that nobody ever read, so we've tried to be concise, and have to make a few assumptions i.e. when we say backup your site and database, we could provide a step by step guide to using ftp and sql server backup, but that would add a lot of documentation that many would already know, and would not be applicable in some cases e.g. intranet users, users with no sql backup.

In short, an upgrade should be simple i.e. simply unzip the new folder over the existing folder (thereby replacing any updated files, and adding the new ones).There are a few key files that we try to protect, as they have user specific settings - these are the web.config file (it contains your database connections and the encryption and validation keys that protect and encrypt user passwords), and SiteUrls.config (which can contain custom url mappings), so we don't include them in the zip with those names to stop accidental overwriting. In the case of web.config, back it up safely first, and then you should rename release.config to web.config (this ensures all new application level settings are correct), and copy back your user specific settings (connectionstring details, machinevalidationkey and machineencryptionkey) and you're done. Now when you visit the site, as the application will have recycled (when the bin folder contents changed), Dotnetnuke will detect the upgraded version, and update the database scripts accordingly.

To answer some of the direct questions:
make sure you always backup your files/database before upgrading to a new version <Does this mean simply FTP my web site locally? If all goes wrong can I simply upload the FTP'd image of my site and it will be back to normal? 
just backup as you would normally i.e ftp/file copy if it's an intranet. You'll have to use whatever database server backup you have, most hosts will allow you to create a backup and restore via their control panel. You will need both a copy of the folder and all subfolders, as well as a backup of the database if you choose to revert to an earlier version.

How is a site shut down cleanly so that no users are logged in before I do the backup? Is this relevant to the hosted files or only to the database?  With regards database backup which are the critical files? Or all they all critical? As many sites are hosted on remote SQL servers it isn't possible to use SQL backup statements, instead data has to be copied. How is the site shut down cleanly in a consistent state so that all data can be copied? - perhaps a SQL specific question, but on that DNN could describe>
that's up to you, some control panels offer the ability to take a site offline, or if you're using asp.net 2.0 you can drop a file called app_offline.htm  to take the site offline. Alternatively, you can use the AutoUpgrade=false functionality we have built in. You need to backup both the files and the database. In terms of the database, if you're using sql, you only have an mdf and ldf file, and when you backup, the ldf is truncated down, and the mdf is backed up to a single file. Most hosts offer backup utilities, if your's doesn't you may need to look at DTS to do a backup of data.

- unzip the code over top of your existing application <I read this as it states, simply unzip the files and FTP them to the host. Is it that simple? What should I be aware of with regards to active users on the site. Sometimes FTP is flaky and times out, is there any file which is the trigger file that should be uploaded last?>
it's as simple as that. I agree sometimes FTP is flaky, theres little we can do. Many people will ftp the files twice, just in case. There is no trigger file, but when the global.asax, web.config or any file in the bin folder changes that will cause an application recycle to happen.

- browse to localhost/DotNetNuke in your web browser <This is on a local machine, what about in a hosted environment?>
where you see localhost/dotnetnuke, you will use your site address e.g. www.mysite.com

- the application will automatically execute the necessary database scripts <As above, how is this managed on a live hosted server?>
it's a built in function of dotnetnuke to detect the version, and see if any scripts have to be run, this happens automatically (note: the scripts are in Providers\DataProviders\SqlDataProvider folder)

As for the 'object reference...' error, this commonly happens when a file is missing, please check you ftp'ed up all content.

BTW, there is also an installation video at the dotnetnuke.com site that may be worth watching

Cathal

Thanks Cathal, this is good info.

I used to be a programmer for monster.com, and I know what you're up against with respect to settings for IIS, SQL Server, privileges, etc. I realize you cannot be a guide for all of the permutations. That being said, I don't think an upgrade is an unusual permutation.

May I make a few suggestions?

1. The documentation called the Installation Guide only refers to unzipping the files after a paragraph that starts with "If you are installing a new instance of DotNetNuke...". This is what threw me. The "new install" and "upgrade" information is mish-mashed together. Separate chapters would be useful.

2. I would think the docs (or a program) would tell me what the minimum subset of files (and their sizes and dates) should be on the host. If you send me a reference to a site with 3.2 and a read-only password I would be happy to do the work for this.

3. Similarly, the same information could be provided for the database. At least for the preferred DB: SQL Server. Incremental scripts are great, but it's always great to know that my schema matches the desired schema. Again, I would  help if need be.

4. When all else fails, a minimal install would be help: this would be an ASPX that simply uses the config, tests for database and folder permissions and perhaps test for the correct files and generates lucid error messages.

Perhaps these things already exist. I could not locate them.

I love this package/product. It is an extremely cost-effective way to a web presence. Let me know if I can be of assistance.

Thanks again,
Dan

1. no problem with that, if the doc's are ambiguous they should be changed. On that note we are forming a dedicated documents team so hopefully that will help improve the readibility of the existing docs, as well as add new ones. Theres also a dotnetnuke project team working on creating an installer to automate the setup, that should help.

2. theres 2 versions. The install is the minimum set of file's you need to install, the source version contains all the code so you can rebuild/recompile the project.

3.that would be a possibility, and could be managed a bit now, as we've decoupled the modules, so the core schema is smaller and easier to compare. In the past community members have supplied chm's/visio's with the schema, so far noones volunteered that information, and noone on the core has created one yet, I will if I get a chance.

4.that's what the installer will provide i.e. it won't install without the minimum requirements. At one point we did have checks to see if the user could create folder's, delete folders (to ensure child portals will work)etc., but this caused issues, as some users lock their installs down and don't let these actions happen i.e. they do a local install, ftp up the files, and never use child portals. This still allows them to update their sites, without needed the anonymous webuser to have modify permissions.

Cathal

As a tip, if you get the "Object reference not set to an instance of an object" error after an upgrade, try recycling the app pool, or if you really want to make sure, stop/start IIS. Nine times out of ten, this solves the problem for me. It's likely due to a caching problem or junk lying around in the .Net temp folder that need to be cleared out.

Also, if you want to upgrade a "live" site and don't have accss to IIS to stop the web site (which is how I do it) before you overwrite the old files, simply delete default.aspx from the root folder. Your users will then get a 404 error but at least they're not updating the database while you're busy uploading. Just make sure you copy the new default.aspx last. If you really want to be nice, you could change default.aspx to show some type of friendly "down for maintenance" message, instead of deleting it.

Always upgrade with autoupgrade=false in your web.config so you have to enter the specific URL to start the update, otherwise the moment you copy the new default.aspx over and one of your users navigate to the site, the upgrade will begin.

Cathal

Thanks for the responses. Having written technical docs for systems I've developed I do understand your point that you can't cater for every scenario! But it is very easy to fall into the trap of assuming knowledge when you have such a great deal of info in your head that is 'obvious' to yourself that it doesn't need stating.

As having a programming / architecture background what I would like to see, and would give me greater confidence when upgrading, would be documentation regarding the underlying architecture and implementation of a DNN site. I'm thinking here of what actually happens at install / upgrade time. What are the dependencies and purpose of so many of the executables that are located in the numerous folders. Which of these folders contains static data / files, which information is created dynamically at install / upgrade time etc.

I made a mistake in my original posting referring to SQL 'files' - I actually mean't 'tables'. I have a great hosting company that is responsive, technology led and reasonably priced so I wouldn't want to change. What I *can't* do though is SQL DB backups in the normal sense of file backups or even synchronisations with my local DB instance. Therefore what would be very useful would be information on the key SQL tables. i.e. if I'm managing a site where users are submitting content - where is that content located? The content is the value of the site and the crown jewels that must be available in the event of any disaster either accidental or via a backup. I would then at least have a copy of the site that could be retro fitted back into a new installation later.

Now I could start to review and read all the source code to work out how DNN functions - but that would defeat the purpose of using DNN as I might as well start with my own IBuySpy portal and grow from there. Indeed this was my original intention until I stumbled upon DNN.

In summary - is there existing documentation that you could point me to regarding the implementation (even paper books, I don't mind spending the money), or do you know if this is something that is in the pipeline?

Thanks

Andrew

Andrew,

I think this is the good news/bad news scenario with Open Source projects. All the time is donated and most of the help has day jobs to support their bad habits of eating, shelter, etc. ;)

I've been pondering this problem for a few days. Based on the useful input from Cathal and looking at the other threads I've come to the following conclusion: I think the core requirements for both install and upgrade processes need to be documented. This has been promised for quite some time (all in good faith, I'm positive) but I need something to keep me sane during upgrades soon.

So here is my plan: I'm going to get the 3.2 minimally installed on a server local to me (so I have permissions) and build a workable reference site. Then I'm going to write a .NET application that uses ftp to compare the reference site against a production site's files and folders and  do the same for database schema (using ADO.NET schema comparisons).

If the core team is listening, please consider these points when thinking about upgrade processes:
a. my production site is hosted remotely. I am not an administrator on their machine (thank goodness, since they host many of us) and I cannot restart IIS, change the ASPNET process, etc. All I really can do is alter my files and folders.
b. I (like most webmasters, I think) would like to keep my site clean. It would be nice to know when files and schema are no longer needed.
c. As Andrew mentioned earlier, I have many users in many portals - they really should be notified in a way that is a bit more friendly than just clobbering them by placing a default.htm file at the root.

As to your question, Andrew: I have purchased two books that are of some help in understanding what is underneath (other than the code, that is), but neither provide all that you (we) are asking for:

1. Building an ASP.NET Intranet ISBN 1-86100-749-3  The original IBuySpy book - probably out of print.
2. VB.NET and DotNetNuke 3.0 ISBN 1-904811-27-2 A bit basic, but a good reference book.

Good luck, and have fun.

- Dan
- Dan

AndrewBF,
Some of the details of the dotnetnuke architecture are detailed in the book written some of the coreteam (partsof the patterns involved are discussed here as well).

Cathal

 

Cathal

Thanks for the pointers - very useful. I'm placing and order for the book(s) today. Should help me greatly in getting to grips with DNN.

Hello theferret

theferret wrote:

Can anyone help me. I have 3.0.13 working just fine and downloaded 3.2 to 'upgrade'. What the heck am I supposed to do with the contents of this zip file? It isn't in Nurse's installation docs (unless it is somehow implied).  They don't expect me to overwrite my portals folder, do they? (do I need to know some kind of secret handshake?).  Thanks much in advance.

Thanks so much for starting this thread. I too feel the same way.  I have the DotNetNuke ASP.NET Portals
and looked up DotNetNuke upgrade, hoping to find the magic spell or learn the handshake.  But the book as far as I can see has only 2 references to upgrading, page 51, which gives a few lines "backed up your file structure and database and you are ready to upgrade " (no detailed instructions) HOW?. Also a few lines on page 253: "One of DotNetNukes feature is the ability to upgrade". (no instruction). HOW?

I felt at a loss, I have been afraid to attempt to try to upgrade. I have my first DotNetNuke site live and I have been putting off upgrading for fear of making a mistake which may cost the site and contents that has taken me quite a long time to create and put it together.

I have read the answers given to this thread with interest, but I have to admit I am still a little wary.  I would be grateful if somebody could take the time out and write an idiots step by step guide to upgrading. Or if you have already written the instructions, please share with the terrified pre upgraders.
 Or do I have this correct.
1. Make a copy of my site/files, by downloading them onto my own computer.
2. ask my website host to made a backup of my database ( I am too scared to try myself, cos I am unsure).
3. Download the DNN 3.2 to my own computer and unzip it.
4. All I need to do is just ftp the unzipped upgrade over my own files on line.
5. Delete the web.config file on line
6. Change the web.config accordingly after carefully reading instructions and ftp to the newly upgraded site.

Is that it, what about the database, what else do I need to change

Could somebody confirm that the above 6 steps is right or wrong.

Thanks in advance.

Hello,

Yes that is correct, just be very careful with the web.config file - make sure you back it up & transfer across your settings.

If you can wait for a day, I am literally making a free video as we speak on how to upgrade to DNN 3.2. I'm going to release it officially in issue 4 on Dec 1st, but once I've finished it (hopefully by the end of today / tomorrow) I will post a link to it here so that you can view it.

Hope that will help, will be back in touch soon, cheers,

Lynn

From what I've learned so far on DNN, installations and upgrades...

DO NOT delete web.config. Always make sure you have a copy of the latest good working copy on your site. The crypto keys used by your site are stored in web.config. If you delete the file and don't have these keys then the passwords to access your site will be useless as they are encrypted using the keys in web.config.

Well, at least that is my understanding of what happens, some DNN guru may be able to explain in more details what actually happens.

Now here's a thought on the upgrade process. Supposing web.config get updated in the upgrade (in the form of a new release.config). How are the new settings in release.config copied over to web.config if web.config has to be retained and copied???