使用Azure SDK 1.7从Visual Studio发布不再起作用-证书/缩略图错误

Question

I have a long-standing Azure Cloud Service project, which I use to deploy web and worker roles to Azure from Studio. The cloud service definition and cloud configuration files include information about certificates that have been uploaded to the cloud service. So, in the service definition:

<Certificates>
  <Certificate name="cert" storeLocation="LocalMachine" storeName="My" />
  <Certificate name="encryption" storeLocation="LocalMachine" storeName="My" />
</Certificates>

and in the service configuration:

<Certificates>
  <Certificate name="cert" thumbprint="[hidden]" thumbprintAlgorithm="sha1" />
  <Certificate name="encryption" thumbprint="[hidden]" thumbprintAlgorithm="sha1" />
</Certificates>

I have been publishing with these configurations and certificates to the same cloud service for a long, long time with no problems.

Now, I have just upgraded to the Azure 1.7 SDK (June 2012) for Visual Studio 2010 sp1. Once I upgrade my cloud service project [in Properties, click "Upgrade"], I am no longer able to deploy, due to an apparent certificate error:

1:25:28 PM - Connecting... 1:25:33 PM - Error: Certificate: 'cert' with Thumbprint: for Role: My.Web has not been uploaded to the cloud service: My Test NC. 1:25:33 PM - Error: Certificate: 'encryption' with Thumbprint: for Role: My.Web has not been uploaded to the cloud service: My Test NC.

Notice that there is no Thumbprint listed at all in the error - I did not remove it here for security purposes.

If I edit the project file and change absolutely nothing else besides changing 1.7 to 1.6, once again deployments from Studio work perfectly.

It seems like there is some trouble with Visual Studio sp1 and Azure 1.7, but I haven't found any evidence of anyone else having similar troubles.

UPDATE: I just talked to Microsoft and we're now at least clear on the reproduction steps:

• there have to be multiple service configurations (eg "Development" and "Test")
• the different environments have to have different certificates (and therefore different thumbprints).

Since one presumably wouldn't want to store production certificates on development machines (esp. because one wouldn't want development machines to have the ability to decrypt encrypted production values - consider, for instance, if a development laptop got lost), different certificates in different environments seems in line with standard best practices.

So, at this point, Microsoft is going to consider whether or not this is something that needs to get fixed. In the meanwhile, the workarounds for Azure 1.7 SDK are: (1) don't use "publish" from Studio; (2) don't use multiple service configurations; or (3) use the same certificates in all environments (not personally recommended by me).

Answer 1

The "answer" appears to be that when you have multiple cscfg files in the same project, using different thumbprints for the same cert name (which one obviously is likely to want to do) you will encounter this issue.

<Certificates>
    <Certificate name="cert" thumbprint="[hidden]" thumbprintAlgorithm="sha1" />
    <Certificate name="encryption" thumbprint="[hidden]" thumbprintAlgorithm="sha1" />
</Certificates>

Thus, if the value of [hidden] varies on say, cscfg files for dev, test, and live, you'll encounter the error you mention when you try to publish to any of them (say test.)

If you delete the cscfg files for dev and live using manage configurations and remove, then try publishing using the remaining test configuration file, the publish will work (at least for me.)

This seems like a defect.

Answer 2

We found yet another case when this issue can be seen. In VS2012.2 the thumbprint of the certificates are in lower case but it seems the Azure management API demands it in upper case. This is a bug in the Management Portal/API side because a thumbprint can be in any case - there is no informational content in the case itself so the check should be case agnostic by the party that performs the check (the Azure Fabric Controller I believe).

I'm uploading an image showing this (Click here for the full resolution image )

Answer 3

Kent, in addition to the workarounds you have provided, you can also transform the config files during the build step. Phil Hoff has a blog post discussing how to do this at http://blogs.msdn.com/b/philliphoff/archive/2012/07/02/transform-windows-azure-service-model-files-during-packaging.aspx .