I think this is where DNN could really use some improvement. I've been a developer for... uh... 20 years now and have been developing in .Net since well.... .Net was in beta! Sheesh, am I dating myself here or what?? :) Ok..enough of the bragging...(And I'm still developing because I choose to.. Never wanted to be a manager and go to the "dark side").
If you look at the forums, you will see post after post all having to do with installation or upgrade problems. Granted, some of these are because of mistakes made by the individual doing the install, but remember, DNN let them make the mistakes. The user didn't purposely "mess up their connection string" just for the fun of it. The whole notion of a "copy files from here to there" seems a little archaic to say the least. And having a newbie mess with a web.config file..well.. that's a recipe for disaster.
But I think there are some things DNN should do to "help" this issue. I don't think they can solve it but I think they can make it less frustrating on those who are not versed in .Net architecture or installation.
- I would think I nice little wizard you could run on your local machine that prompts the user for their connection settings in an "MSI-like" interface, then writes out a web.config file with the connection settings, (Connection Strings...can they be any more cryptic to a non-techie? Nuff said.) http modules, provider settings, trust levels, object qualifiers, etc.. that they chose as they walked through the wizard would help the situation somewhat. The wizard would write out a "deployment package (a.k.a. zip file)" with all of the DNN Code needed, the appropriate directories, etc..that you can copy to your host and unzip.
- Hitting the default URL to launch an upgrade is kind of dangerous IMHO. It should be a hidden URL that you type into your address bar that actually launches the upgrade when ready. I often wonder after I finally ftp and extract all of the 11,000 files and then fix up my web.config on my server if one of my website users is running the upgrade because they hit the website before I did?? You guys did such a great job with installing modules via the module definitions page, it seems that same paradigm could be used for doing an upgrade or installation?
- Speaking of 11,000 files. What drives me crazy is a simple minor version upgrade. I don't want to copy the whole installation up to my server and have to reset all of my permissions on my folders (because my host provider doesn't have a good tool) to perform a simple minor version upgrade. Can't we also have an "upgrade package" that contains ONLY the modified ascx files, dll's, and vb files, and sql scripts necessary to do the upgrade instead of the 11K files that make up DNN? This would be like a Service Pack from Microsoft replacing EVERY dll, ocx, exe regardless of it being changed within the service pack. No one would stand for that as it would be like essentially re-installing windows for a simple security patch to IE.
- It seems that file permissions are also a re-occurring issue. The features.config, or siteurls.config or compression.config don't seem to get copied from the config folder to the root because of the way certain hosts have things set. And the code subdirectories don't always get written to the web.config file as .Net 2.0 has a problem with accessing a higher level directory even though it's in the same app domain. Maybe the installation should just have those in the root to begin with?
And no offense core team, but your error trapping is..well horrendous. I've modified the source quite a bit and I've poked around a bit. I see no checks for null parameters which always lead to the dreaded (Object reference not set to an instance of an object). I constantly remind my team that a simple check and a clearly written error message can solve hours (maybe even days) and thousands of dollars in debugging time. Add that up per bug and you come up with a lot of bucks. Just because you think the parameter will NEVER be null, doesn't mean it won't be. :)
Either way, I encourage the core team to look at the forums. What percentage of posts start with "Help..Installation error" or "Help.. Upgrade error"... Now, you can "blame" it on a "stupid user" but it seems unlikely that so many would be having the same problems if the installation/upgrade paths were uh... "idiot proof"
And I know what you all are thinking. Quit whining and become part of the solution.. All I can say to that is Touché :)