Thursday, 16 April 2009
Or, put another way: why don't we just use the web.config file? This question was recently posed to me and I thought I would share an answer more broadly since it is a fairly common question.
First, the web.config is part of the deployed package that gets loaded into a diff disk that in turn is started for you app. Remember, we are using Hypervisor VM technology to run your code. This would mean any change to this file would require a new diff disk and a restart. We don't update the actual diff disk (that would be hard with many instances) without a redeploy.
Second, the web.config is special only because IIS knows to look for it and restart when it changes. If you did that with a standard app.config (think worker roles) that doesn't work. We want a mechanism that works for any type of role.
Finally, we have both staging and production. If you wanted to hold different settings (like a different storage account for test vs. production), you would need to hold these values outside the diff disk again or you would not be able to promote between environments.
The cscfg file is 'special' and is held outside the diff disk so it can be updated. The fabric code (RoleManager and its ilk) know when this file is updated, so it will trigger the app restart for you. There is some short period of time between when you update this file and when the fabric notices. Only the RoleManager and fabric are aware of this file - notice that you can't get to the values reading it from disk for instance.
And that is why in a nutshell, we have the cscfg file and we don't use web.config or app.config files.
All that being said, I don't want to give you the impression that you can't use web.config application settings in Windows Azure - you definitely can. However, any update to the web.config file will require a redeploy, so just keep that in mind and choose the cscfg file when you can.