1. Nice post, thank you for hints. Do I understand properly that when you upgrade your deployment with re-publishing – you won”t be able to upload old packages anymore ? So if you want to restore some older versions – you cant deploy it to upgraded cloud service instance, right ?
    Does same upgrade could be “applied” to Azure Storage or SQL Azure instances, or only to Cloud Service ones?

  2. Hi centur,

    Re: uploading previous packages after upgrade. I havent tested this, but I would imagine so – since they specify an older version of the SDK. I dont know if Azure would downgrade your deployment when you upload your previous package – it might – or it might just fail it. I am pretty sure though that it will delete/recreate a deployment (instead of upgrading) when the SDK version changes.

    Re: Azure Storage of SQL Azure – these are not instances you manage but Azure services Microsoft manages, so this upgrade is not “applied” to them. However, the new Azure DLLs you reference in your code do contain fixes/changes for how your code talks to Azure storage – as long as you reference the new StorageClient.dll assembly. Check out the azure storage blog for more on what they changed.


    • Thanks. I understand what is Azure Storage and SQL Azure is, but I thought there could be some API fixes and changes, which could lead to some kind of upgrade to new api should be applied. Surely new DLLs send new Version header, but I think that it could be more complicated with all that geo-distribution and load balancing.
      Could I ask few more questions:
      Does deployment upgrade affects only concrete slot (ProductionStaging) or it affects entire Cloud Service?
      Is there any option to upgrade deployment not using Visual Studio? Some kind of API call or Management Portal “upgrade” button ?
      Will we still be able to use “Swap VIP” to switch from old 1.6 SDK deployment to new 1.7 one to avoid service downtime ?

  3. Ben

    Thanks for this; seems to have fixed my problem, I only wish I”d found it before burning the midnight oil.

  4. Dan

    Thanks , I got my problem fixed. We had a common library that was shared via nuget. When we upgraded the sdk, one of the applications start throwing the error. This post helped me .

  5. Great post, we just upgraded, and in addition to your steps I also had to modify my .config”s as we had trace listeners defined that referenced

    which we changed to

    You probably coverd it in the upgrade your references line, but when I read that I am thinking of .csproj files, and the version in there, I had totally forgoten about the trace listener”s – so I thought I would leave a comment incase it helps the next person…

    Thanks again for a great post.


  6. Adolfo

    Thanks Mike for this great tutorial. Came across it when searching for a solution to a much similar problem. Mine is with version 1.8 of the SDK and although symptoms are all the same, the steps you propose did not completely work form me.

    I keep investigating 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *