Kevin Hoffman

One of the double-edged swords of Azure is that it feels so much like building regular web applications. This is a good thing in that you can re-use so much of your existing skills, knowledge, and best practices and they will still apply in the Azure world. However, it is really easy to make assumptions about how things work that turn out to be wrong.

For example, if you look at just about 99% of the Azure samples, blogs, and other reference material, you will see stuff that looks like the code below, sitting right inside web.config:

<add key="TableStorageEndpoint" value="http://foo.table.core.cloudapp.net"/>
<add key="QueueStorageEndpoint" value="http://foo.queue.core.cloudapp.net"/>
<add key="BlobStorageEndpoint"  value="http://foo.blog.core.cloudapp.net"/>
<add key="AccountName"   value="foo"/>
<add key="AccountSharedKey"   value="...lotsa stuff..."/>

If you were to make assumptions about this, one might assume that you should be putting stuff like this in your web.config file even when you go to staging and production. NO! Stop right there!! This is not how Azure configuration settings are supposed to work!

Equally prevalent in the samples you will find calls to methods like GetDefaultTableStorageAccountFromConfiguration. there is actually a bit of useful logic going on in here that might not be immediately obvious.

This method is going to make attempts at getting configuration information from multiple different locations. It will check the web.config/app.config file, but it will also check your service configuration file. The most important thing to remember about this file is that it can be edited directly from the Azure portal. This means that you can deploy your application to stage and then go in and edit the service configuration file to change all the endpoints to your staging endpoints, then activate your app.

The reason this is important is because you never, ever, ever want to include your Azure key information in your web.config file, especially if you're posting on forums or sharing your code with other people. This is because if anybody gets your account name and shared key combination, they have full access to your Azure storage account and can basically run amok all over your data.

So, how do you know when you use a service configuration setting vs. a web.config setting? Here's a quick rundown:

• If you need to be able to edit the information after deploying, it must be in service configuration and not in web.config
• If the information only changes once per full deploy to production, e.g. it's version bound not environment bound, you can leave the setting in web.config

So, for example, in a typical Azure application, you might store the names of your queues and tables in web.config (because they should rarely change and will remain the same between stage and production), but you'll put the endpoint information related to your Azure Storage account in the service configuration file.

Hope this helps. The key thing to remember is that Azure service configuration can be a really powerful tool if you know its there... it can also screw you up if you forget its there :)