So I’ve upgraded to Community Server 2.0 – here’s my story:
Why?
I was looking for some issues (defects) to be addressed, podcasting support, and the redesigned control panel and management tools. I was also looking for .NET 2.0 support.
How?
First, I did an upgrade in my dev environment.
1) I downloaded Community Server 2.0 (Web Install) – ASP.NET 2.0 and unpacked that .zip file.
2) I backed up my database and copied the web files
3) I restored my database and set up the web files locally so I could then hit the site as nino.mydomain.com
4) I (gasp) read all of the README files in CS 2.0
5) Since I was going straight from CS 1.1 to CS 2.0, I executed CS_1.1_to_2.0_upgrade.sql
6) Since my CS site is on a hosted web site, .NET 2.0 is remanded to running under medium trust, with no ability for me to override that, I need
to leverage the ASP.NET 2.0 Medmbership functionality, so I execute CS2.0 Update Membership to ASPNET2.sql
7) Instead of overwriting my existing files with contents of the CS2 /Web directory, I deleted all the web files and replaced them with the contents of the /web directory.
8) I updated the database connection strings (yes, there are two) in the web.config.
9) I changed the machine-level web.config to medium trust
9) I hit the site – it comes up. I walk though a number of admin things and verify that all is well
Now that the dev site is working, I figured I’d have the same ease of upgrade on my production site (heh). I proceded to execute the steps I just did on my dev site beginning with step 5. I see errors. Some of them fairly benign, some not, and some just plain odd. *sigh* Against my better judgement I decide to execute the script from step 6 as well. More errors. At this point I’m a bit unclear as to why I’m getting errors that I did not get in my dev environment (which is a backup of the production environment). Of course, also at this point, my blog is pretty much useless short of a db restore (which is no instant matter given that my db is hosted). So, what to do?
I decide to take the impatient optimist approach (if you can call it that) – I decide to put the web files in place and see what is broken and move forward from there. I complete steps 7 and 8 (and I turned off custom errors in the web.config). I start working through the errors and running individual bits from the db upgrade scripts. This is going to take awhile, so I think that a faster approach would be to diff the two databases and see what’s out of whack. I grab a trial edition of Red-Gate’s SQL Data Compare (which, by the way, is really slick) to generate a difference script. I gen’d a diff script - twice (just in case). I applied the diff script. Errors. *sigh* I hit the site again – more stuff works. I actually run the diff script again (which fixes more stuff while additional errors are thrown).
At this point, most of the stuff in CS2.0 works, although I can’t create new blog posts (of primary concern to me) and a few other small details. So, what to do? More debugging? Nope. This is where is the “impatient” part comes in. I’ve sunk several hours in already, and well, decide to short-circuit the matter. I take a backup of my dev db, FTP it up to my site and send an e-mail to the support alias to get it restored over my production db. The swell folks at Server Intellect respond pretty promptly (better than the folks at my old host, but more on that later) and restore my dev db backup into production. Sweet. Oh yeah, I also got a backup of my futzed-up db for analysis later.
Summary
So, outside of the snafu with updgrading the production database, it went pretty smooth. I’ll take a look at the futzed-up db this weekend. I also realized tonight that I have another issue to address – URL redirects. I previously solved this using a redirect handler which don’t work (out of the box) on ASP.NET 2.0, so I need to do some work.
I also have some work to do around re-skinning the blog, updating links (blogroll anyone?) and such.
Update:
I've gotten a few comments (well, not post comments, obviously) about my decision to do the restore vs sorting it out. Here's the deal: I had sunk several hours into sorting the issues (more than I had expected) and needed to get it running ASAP so I could devote time to other things. You could make a parallel between my 'restore or debug' decision and the classic 'build vs buy' decision. Could I have debugged it? Yep. Furthermore, I might have just taken the course to do a restore on my working dev db from the start and avoid attempting to upgrade my production db, but I, obviously, didn't think about going that route from the beginning.