Home/ Questions/Q 6639553
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-25T23:34:01+00:00

I’ve just migrated and deployed my first Azure Web Role this week and now

  • 0

I’ve just migrated and deployed my first Azure Web Role this week and now that the pressure is off to get it deployed I’m reading “Azure in Action” and after reading about configuration settings the whole thing rubs me the wrong way.

This seems fine for migrating AppSettings type configuration settings. However, what about settings in system.web, system.webServer and system.webService or other more complex configuration systems. If I want to be able to modify my WCF configuration settings my current options are:

  1. Make the change and do a full deploy (build, upload to staging, switch VIP)
  2. Extend WCF thru a custom behavior or whatnot to use the Service Config (cscfg) instead.

I thought maybe I was misunderstanding the use – like the examples were simply the very naive case and that in practice they were used differently. However, after googling for a while it seems that this is exactly how everyone is doing it. For example, instead of using the connectionStrings configuration element for Entity Framework connections I have to write a custom connection factory.

This not only seems like too much work, but it ties my entire configuration implementation to Azure. Yes, I can use an interface so I can abstract the details and replace the implementation if I need to. But I still don’t like all the extra work, connectionStrings are simple, but there are much more complex things to override.

What I’m thinking is that I should be able to do is read the Service Configuration at startup and use the ConfigurationManager to update my web.config. If something changes at runtime then again, I can update web.config. This way my application is still portable and I’m not hardwired to the Azure configuration system.

Does anyone agree? Or is it just me?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    What I’m thinking is that I should be able to do is read the Service Configuration at startup and use the ConfigurationManager to update my web.config. If something changes at runtime then again, I can update web.config. This way my application is still portable and I’m not hardwired to the Azure configuration system.

    In that case, what would happen if Azure restarted your role? The configuration would revert to that in the Service Configuration. If you’re running multiple instances, configuration can then differ between them with potentially dangerous results.

    An option is to build (once) a customer configuration provider that picked up settings from somewhere else (such as Table Storage) rather than web.config or .cscfg

    With your configuration provider abstracted behind an interface, you can exploit Dependency Injection to provide the appropriate configuration mechanism for your deployment model.

    I feel your pain, but it’s really only a problem that needs solving once.

    • 0