locked
CMAB and development vs production configurations RRS feed

  • Question

  • User1940267948 posted
    I'm currently evaluating the CMAB and am trying to decide whether or not to use it for my ASP.Net application. One thing that has always bugged me about the built-in configuration system with .Net and ASP.Net is that there isn't an easy way for developers to establish local "development" settings which override standard "production" settings for an application. You can do this to some degree using the <appSettings file="dev.config"> configuration directive, however this is not comprehensive (you can't use it to override say, FormsAuthentication parameters), and it doesn't allow for more complex configurations (other than the key/value pairs available via ConfigurationSettings.AppSettings). I was hoping that CMAB would address these issues, but it doesn't appear to... So my question is: Is there any way to configure CMAB to switch between two complete settings configurations in a manner similar to that of the <appSettings file="dev.config"> override? I realize I could create a custom ConfigSectionHandler and write this functionality myself, but that is true with or without the CMAB... is there anything inherent in the CMAB framework that addresses this?
    Monday, September 29, 2003 8:33 PM

All replies

  • User-1753772650 posted
    Hi, yeah, well said! There's an interesting thread which (in part) looks at question of dev vs prod at http://www.gotdotnet.com/Community/MessageBoard/Thread.aspx?id=114321, but does not solve my problem... I was hoping to recommend the use of CMAB to my team where they: - use (application-root relative) XML files for dev config - use database for test and production config Since we have ~30 function-test, load-test and production server instances in 3 server farms (in 3 timezones!), db-centralised config will be very welcome! We've strictly divided our configuration per app. into one config-section per namespace used; CMAB supports config by config-section name, so that's ok - except that: 1. different applications configure the same namespace (dll) config-section differently: that is, the config-settings are dependent on the application instance and the config-section (namespace) name, not just the config-section name. "Well that's meta-config" you say, and you're right. No problem for XML file meta-config for dev and : just point to application-relative path'd config files. But what about database-based meta-config? Am I forced to have a different db connection-string for each application (instance) that uses the same config-section (namespace)? A new catalog per application config?? Errrk. I reckon the CMAB db schema needs a meta-config'd "appConfigId" to group a set of config-section params to a particular application instance. 2. different versions of the same application in production need different config-settings per (server) instance; eg: a new version of the app requires new/altered config settings, and we need to deploy the new version server by server: during the "seamless" upgrade, the same application has two different sets of config settings, used by different instances, at the same time. Again, I don't really want a new connection-string per version of the config-settings per application!! So now I need to add a meta-config'd "appConfigVersion" to the db schema as well. No big deal: I can add this extra meta-config without changing the config store API, but will need to change the SQLStorage class & stored-procs. If I'm happy with the results I'll suggest the changes back at the gotdotnet workspace. Meanwhile, has anyone else pondered these issues? Cheers Garth
    Wednesday, January 7, 2004 10:10 PM