Upgrading to Windows Azure Tools 1.7

At GoldMail, we like to be using the most recent version of the Azure Tools and SDK for two reasons. One, we can take advantage of the newest features, and two, we don’t get too far behind, which may cause problems down the line. This can be problematic, as we have a lot of services, a lot of other work to do, and the Azure team is pushing out iterations pretty quickly. They were coming out every 3-4 months until this last one (June 2012), which was almost 7 months.

All of our infrastructure runs on Windows Azure. The exceptions are the desktop client (WinForms) and the Flash player. So when we update our tools version, it impacts everybody in Engineering, and our build engineer in Operations (we call him Awesome Jack).

The new version of the Tools/SDK (1.7) will run side-by-side with the previous version (1.6) (thank you Microsoft!). From information provided at the MVP Summit, I knew this was going to be the case, so we updated to 1.6 in March, which was a small update that didn’t impact us. This would allow us more flexibility when updating to 1.7.

Upgrading from Tools 1.6 to Tools 1.7

First, I installed the new tools/SDK on one of my personal computers rather than my work computer. This way, if I have any problems with the service or application running with 1.7, I can work on resolving the issue, and I can still get my work done.

I compared the manual installation instructions for Tools/SDK 1.6 against the manual installation instructions for Tools/SDK 1.7, and determined that I only had to install the following:

  • Windows Azure Authoring Tools
  • Windows Azure Emulator
  • Windows Azure Libs for .NET
  • Windows Azure Tools.VS100

If you’re running VS 2012, you can install Windows Azure Tools VS.110.exe instead of VS100 – we haven’t upgraded to VS2012 yet. (Since that changes the development UI, that’s a whole different upgrade project!) The instructions for 1.7 also talk about IIS Express and SQL Express Local DB, but I have full IIS SQL Server Developer’s Studio installed, so those are unnecessary.

The rest of the instructions and other installs, such as  the URL Rewrite module, are the same as those for 1.6. So I only installed the Tools/SDK bits, carefully reading each License Agreement, just like everybody else. (Haha!)

So let’s see how to update the Visual Studio project. I’ve opened the Customer Services WCF service that is created during my Azure for Developers talk. Because I still have Tools 1.6 installed, I don’t get prompted to upgrade my project. But I want to do the upgrade, so how do I force the solution to upgrade? Right-click on the Cloud project and select Properties.

Now the properties of the cloud project are displayed. It recognizes that I have a newer version of the Tools installed and offers me an upgrade.

I click the Upgrade button and get the Visual Studio Conversion Wizard.

I click Next, and get the screen asking if I want to create a backup before the conversion is performed. (For solutions bound to source control, I always say no, because isn’t that the point of source control??)

I click Next and I get the Ready To Convert dialog, where it warns me about source control.

I click Finish, and I get the Conversion Complete dialog.

I check the box to see the conversion log because I’m nosy and I want to know what got changed, then click on Close. The log is displayed:

Among the changes, it looks like it added a Schema Version to the csdef and cscfg files. You can now see this in the csdef file at the end of the Service Definition element in the csdef file, and at the end of the Service Configuration element in the cscfg files:


Now that it’s upgraded, I just need to publish it to one of my staging services and test it out.

How do we schedule upgrading our services at GoldMail?

It would impact the development schedule too much to publish all of the services to staging, test all of them, and move them into production. So this is how we handle these upgrades.

  • I put a work item in to TFS to for the upgrade of each service or application. (I want to be sure I can track each one separately, because we’re not going to release them simultaneously.)
  • For each service or application: I open the source code in Visual Studio and update the cloud projects. (Note: if you have more than one project, you need to update each of them.) Then I publish the project to staging and (assuming that worked) shelve the changes from the upgrade.
  • If the deployments work, I’ll do some cursory checking to make sure there aren’t any immediately obvious showstoppers. Then I will check in all of the changes. (No guts, no glory).
  • At this point, the other developers and the build engineer have to install the new tools/SDK. Until they do, they won’t be able to open any of the projects. (It’s best to check and make sure they’re not in the middle of something before checking in the changes!)
  • For each service, if we are currently working on it, I assign the work item for upgrading that service to that release. If we have an upcoming release that we haven’t started working on yet, we wait and include the Tools update with that release.

We are constantly working on the different products, so usually this will end up with most services being upgraded in 2-3 months. At that point, we will test whatever’s left and then release it.

If there is a feature we really need to use, we will accelerate the release schedule. But otherwise, this kind of lazy upgrade schedule works really well for us, even though it takes a little longer. Tools/SDK 1.6 came out before we’d finished upgrading everything to 1.5.

Of course, since 1.6 and 1.7 run side-by-side, we could wait and upgrade each product before we are going to make other changes, but I’m always afraid we’ll forget upgrade something, and this way ensures that we get everything updated eventually.

3/8/2014 GoldMail is now doing business as PointAcross.


7 Responses to “Upgrading to Windows Azure Tools 1.7”

  1. Windows Azure and Cloud Computing Posts for 7/6/2012+ - Windows Azure Blog Says:

    […] Shahan (@RobinDotNet) described Upgrading to Windows Azure Tools 1.7 in a 7/4/2012 […]

  2. Visual Studio build and publishing problems after upgrading to Azure 1.7 SDK « Mike Volodarsky Says:

    […] The official way seems to be using Visual Studio project properties of your Windows Azure project after installing the Azure SDK 1.7.  Here is an example. […]

  3. Malathi. P Says:

    Regarding migrating web application to azure containing- 1)import from excel sheet 2)Dynamic table creation & handling. Please give clarification. Thanks in advance.

    • robindotnet Says:

      I’ve already addressed #1. I don’t know what you are referring to for #2. Are you talking about Windows Azure table storage, SQL Azure, Mongo DB…?

      • Malathi.P Says:

        Dynamic table creation & handling of sql is used in.net web application. Can application be migrated to windows azure and database to sql azure

        • robindotnet Says:

          I don’t know enough about your infrastructure to judge that, but I’ll say “probably”. I would go to http://windowsazure.com and sign up for a 90-day free trial and try it out! You can also try it in the local compute emulator without signing up for an account (but where’s the fun in that??)

  4. Windows Azure Tools 1.7 へのアップグレード « Mimori's Algorithms Press Says:

    […] https://robindotnet.wordpress.com/2012/07/04/upgrading-to-windows-azure-tools-1-7/ since 1.6 and 1.7 run side-by-side, we could wait and upgrade each product before we are going to make other changes […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: