What I think how the Azure .Net SDK upgrade tool works behind the scene

I am not sure if this a 100 % correct, but from the observed behavior at work, upgrading Azure SDK (say from 1.8 to 2.2., or from 2.2 to 2.3, etc.) using the tooling that is integrated into Visual Studio seems to only update the references that belongs to projects that are referenced in the Azure Cloud Service project being upgraded.  Any other Azure DLL references elsewhere in your solution, WILL NOT be updated automatically.

For example, your solution looks like so:

Solution A (created using SDK 2.2)

• Cloud Service Project
  • Web Project 1
  • Web Project 2
• Cloud Library Component (has Azure DLL references i.e. Storage, ServiceRuntime)
• Data Access / Repository Component (has Azure DLL references i.e. Storage, Cache)
• Web Project 1 (has Azure DLL references i.e. ServiceRuntime, Configuration, Diagnostics)
• Web Project 2 (has Azure DLL references i.e. ServiceRuntime, Configuration, Diagnostics, Cache)

I know… this is probably not how it should be done, but for the sake argument, this is brown field project that you inherited and tasked to upgrade to the newer and shinier Azure SDK.  Ideally, it would be nice if you can centralized the changes to a single project, but in reality, all sort of weird legacy things happen…

Given the solution structure, what we think Azure upgrade tool does under the cover is something like:

1. Figure out what projects are references in the Cloud Service Project.  in this case it’s Web Project 1 and Web Project 2.
2. Update all .cscfg and .csdef file to use the new SDK schema, etc.
3. For all the projects found in the Cloud Service Project, look at all Azure DLL references in the project reference, and update it to point to the new SDK dll (i.e. in C:\Program Files\Microsoft SDKs\Windows Azure\.NET SDK\v2.3\ref).  Look as well in the respective web.config (maybe in app.config as well, not sure) and update and reference to the new Azure SDK dll.

To save cost, we use this trick where we have a webrole.cs inside our web project that is sort of doing what additional separate worker roles might do and this will need its own app.config inside the web project in addition to web.config since the webrole.cs will not run in the same application domain  / process as the web application itself and therefore will not get its configuration from web.config.  Rather, it will pull its configuration from the app.config in that same web project.  What we found is that the app.config is not being updated by the Azure .Net SDK upgrade tool.

In this case, only Web Project 1 and Web Project 2 Azure dll references are updated.  The Cloud Library and Data Access components ARE NOT updated even though they might be referred to by Web Project 1 / 2.

Azure .Net SDK upgrade choices

Given the situation, you can choose to:

1. Spend the needed time to refactor the solution and try to get all stuffs that relate to Azure centralized in a project, abstract it behind some sort of interface.  This could be a nice thing to have.  Added benefit is that you can, in theory, abstract out all Azure dependencies in that particular project and deal with a higher level abstraction that will give you an agnostic way to access cloud related stuffs… perhaps this is useful as well if you want to move your cloud dependencies to other cloud vendor such as AWS.
2. Bite the bullet on the technical debt and manually re-reference the Azure DLL that are skipped by the upgrade tool.  Perhaps figure out a way to automate this as well…
3. Hope that Microsoft to fix their Azure SDK upgrade tool in Visual Studio to crawl Azure dependencies from the entry points and upgrade those references as well.

What We Did

What we did at work was to go with option 2.  We manually updated Azure .Net SDK references in Cloud Library and Data Access components to be on par with what is in the tool updated web projects.  It would be nice if the tool that comes with the SDK do this automatically... wishful thinking.

We also toyed around with the idea of pulling the Azure DLL dependencies via nuget package and script them somehow, so the next time around we need to upgrade the Azure SDK, we just do a minor change in the PowerShell script and run it which will cause it to update all the Azure DLL references to the new SDK level.

Official Azure Nuget Packages Inconsistencies

Some other weird thing that we found… It’s not very clear which way we should go since half of the Azure DLL can found (officially) as nuget packages such as Storage and Cache, but some others like Service Runtime are referred from the ref folder inside the SDK installation and do not have any official nuget package associated with it.  We did find unofficial nuget package for it though such as Unofficial.Microsoft.WindowsAzure.Diagnostics.