Multiple Service Configurations for a Windows Azure Cloud Service

In the PDC '08 release of the Windows Azure Tools for Microsoft Visual Studio, when you create a new Cloud Service project, that project will contain associations to 0 or 1 web roles and 0 or 1 worker roles.  It will also include a single Service Definition and single Service Configuration files.

You'll notice that you can't add additional definition or configuration files to the project either.

This effectively means that you can only have one configuration of your roles and one set of settings.

Some of the scenarios that we want to open up in the future (sorry, no time frame available) are:

• Support for configuration settings that would be used locally, on staging and on production
  • That way you don't have to manage multiple files or comment/uncomment sections manually to run against Development Storage locally, a staging storage account when running your Cloud Service on staging and your production storage account when promoting your Cloud Service to production.
• Support multiple role configurations (i.e. a configuration that contains only a worker role along with a configuration that contains a web and worker role)

We'd need to think this through and provide an end to end solution that meets your needs both on the development side as well as the deployment/management side.  That is, the solution would involve more than the tools, it would involve the SDK and the Portal as well.

To that end, if you have feedback that can help us better understand your needs -- please contact me through this blog or on the forum.

That said, there is a workaround that may be of some use to you today -- that is to have more than one Cloud Service project in your solution.

In an existing Cloud Service project where you want to support multiple configurations, right click on your solution in Solution Explorer and Add -> New project... -> Blank Cloud Service.  (I am starting with my Simple Table Storage example)

You will now have 2 Cloud Service projects in your solution where the active project will determine which roles and configuration files will be used:

In my sample, the new Cloud Service project is named "SimpleTableSampleCloudStorage".  The idea is that the configuration for this Cloud Service will access the Windows Azure Cloud Storage while the existing one access the Development Storage.

You'll notice that there are no roles in the SimpleTableSampleCloudStorage and that it is the startup project. (it's bolded)

I right click on the Roles node and select Add -> Web Role project in Solution...

and then I select the only project listed, SimpleTableSample_WebRole.

Next, I open up the ServiceDefinition.csdef file and add the configuration settings by adding the following to the <WebRole/> node:

     <ConfigurationSettings>
      <Setting name="AccountName"/>
      <Setting name="AccountSharedKey"/>
      <Setting name="TableStorageEndpoint"/>
    </ConfigurationSettings>

I then open up the ServiceConfiguration.cscfg and add the values:

     <ConfigurationSettings>
      <!--Windows Azure Storage-->
      <Setting name="AccountName" value="<insert account name>"/>
      <Setting name="AccountSharedKey" value="<insert Access Key>"/>
      <Setting name="TableStorageEndpoint" value="https://table.core.windows.net"/>
    </ConfigurationSettings>

Now, when I run, since SimpleTableSampleCloudStorage is the startup project, I get the Service Configuration contained in that Cloud Project.

When I make SimpleTableSample the startup project:

and run again, I get the local development storage settings.

Note that the Cloud Service you choose to publish from will affect the Service Definition file that is uploaded to Windows Azure. You also need to double check that you are uploading the Service Configuration file you really want -- they'll look the same and only differ by path.

For an example of how this workaround is used to support different role configurations of the same projects, have a look at the Thumbnails sample in the SDK which contains a Cloud Service project that has both a web role and a worker along with a Cloud Service project that only contains a worker role

Finally, please understand that this is just a workaround that has its pitfalls (it's still pretty hard to manage and doesn't do anything to solve staging and production configurations) but hopefully some of you will find this helpful until we design and implement a better solution for you.