I've finished two complete migrations from
my living room the Inner Drive Technology Worldwide Data Center to Microsoft Windows Azure web sites. Astute readers may remember that in one case I moved to the Web site offering and then moved it to a full-fledged Web role. Well, today, I moved it back. Even though I'm still on the free trial, it turned out that the Web role would cost $15 per month, which, for a site that gets one or two visitors per day, simply wasn't worth it.
Moving the second site, a silly thing from 2004 created to share photos and commentary about a 10-year series of Presidents Day parties a friend of mine hosted back in the day, went a lot more smoothly:
0. I archived the project after its last deployment to the Web, which was in November 2006, when the Web server went online. (The age of this particular server is one of the reasons I'm moving everything to Azure, in fact.) I use SourceGear Vault for source control. So all the source code still lived in the Obsolete repository.
1. The old source code was C# 1.1 code from 2004, so the old project and solution files were in Visual Studio 2003 format. Forget upgrading; I just created a new solution.
2. Some of the code files in the Obsolete area were shared with other, obsolete projects. I branched them.
3. In source control, I moved files from the obsolete folder to new folder, except for obsolete configuration and code files. Vault doesn't automatically fetch the files when you do this, to prevent disasters. That was helpful.
4. Here I ran into a minor Visual Studio annoyance with its project naming schemes. I want the Web project to have a different, standard name for Web projects, so I had to rename it by hand in the file system and in the .sln file. No big deal.
5. Now I bound the new solution to source control. The procedure has to do with my source control setup, and may not be typical:
- Got latest files from Vault in their new locations.
- Added the files to the solution and project.
- Closed the solution
- In Vault, manually added the .sln and .csproj files
- Reopened solution and changed the source control bindings
6. Added references to current version of Inner Drive Extensible Architecture:
- Wound up replacing global.asax.cs with the version from Boxer's Shorts. The party site's was too old to bother updating.
- Added references to InnerDrive.Azure, the Azure mail provider, etc.
7. Reviewed the code throughout the project to ensure nothing in them should prevent a quick compile:
- Converted the project files to Web application. This adds designer files to all Web forms with code-behind files, so Visual Studio can compile the site down to a deployable assembly.
- Went through each page to make sure the designers and the pages match
- Built the project (without running it): OK.
At this point I'd spent about 50 minutes on it. So far, so good.
8. Updated configuration files (web.config, email configuration, etc.) to match the new versions of Inner Drive code files.
9. All Inner Drive websites get page metadata from a data tables, so I had to add the site's metadata to the SQL Database running in my Azure account. This is scripted, and the scripts, moreover, are idempotent to allow for easy automation.
10. It turned out that half the photos and two of the pages on the site weren't in source control after all. Short pause to fetch them from the current Web server and add them to the repository.
11. Compile and run in Debug mode: Yay! Evertyhing works! Time elapsed: 90 minutes (including getting my salad out of the fridge and answering a colleague's questions about something unrelated.)
12. In the Windows Azure portal, created a new Web site, and dowloaded its publish profile to the Visual Studio solution.
13. Right-clicked the Web project and clicked "Publish..."
14. While the publication went on (there were 3.6 Mb of photos to copy up to Azure), updated the production Pages tables with the site's page metadata.
15. Publication completed and...crashed immediately. Crap.
16. Uploaded a new web.config file with <customErrors mode="Off">
"The page cannot be displayed because an internal server error has occurred." That's not helpful. And it led to some thrashing before I realized the PEBCAK:
- Removed the local-only sections of web.config
- Stripped down the MessageConfig.xml to do absolutely nothing
- Check the /LogFiles folder on the virtual machine about 20 times only to see it's empty
- Check the Azure portal's "Configure" tab and turned on diagnostics
- Oops. There it is: "Configuration file is not well-formed XML"
- Uploaded a new web.config file with <customErrors mode="Off" /> (notice the terminating slash).
17. "Could not load file or assembly 'Microsoft.WindowsAzure.ServiceRuntime, Version=126.96.36.199, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified." No problem, I've seen this before. Fixed it.
18. Reloaded the page: success! Except all of my messaging was turned off from the debugging at step 16, so I just had to add them back.
And it only took 2½ hours, including lunch and talking to colleagues about something else. Next time, I hope to do it in a lot less time.
Unfortunately, I can't share the URL, because the content is old and unflattering. Those of us who attended the parties may want to remember them, or figure out what happened in cases where we can't actually remember. But it's not for general consumption.