On 09/01/2012, at 10:51 PM, Lars Corneliussen wrote: > In NPanday we would like to unify how configuration is handled. The main goal > must be to create and distribute environment-unspecific packages. NPanday > should prevent the developer from accidentally including sensitive > configuration elements like connection strings e.g. in (public) packages. > > This is why we do not want to "just xcopy" all config files into the packages. > > But rather we'd like to find a good generic approach to handling config files. > > Wanted behaviour: > > 1) Instead of "Debug" and "Release", "Cloud" and "Local" we use "Package" all > over.
For Debug/Release I agree (with a global property available to set a particular configuration). These are baked into the package, so you want as little in there as possible. Hopefully, they can still select Release and have put their connection strings, etc. outside the web config. For the service configuration - these are separate files, easily changed - and if present and part of the build they are presumably in source control, and should be fine in the artefact repository. I think it might be ok to attach the Cloud configuration (and others selected) if they are there, with a best practice to supply them separately. > > 2) For Azure, by default, ServiceConfiguration.Azure.cscfg is distributed; it > is a COPY, not a transformation. Should we support transformation here? XDT, > XSL? I don't see any reason to add that, myself. It seems quite hard to achieve in VS: http://stackoverflow.com/a/5185380/237237 > > 3) For Webs and Apps we use web. or app.package.config and copy it over as > web. or app.config. Currently this also is a copy, but the plan is to make it > a XDT transformation that then is applied to the main web. or app.config. > > If the *.package.config file doesn't exist, it prints a warning. I think it > should actually FAIL!! But should it rather fallback to web/app.config with > the risk of including sensitive settings in the packages? I think it is reasonable to fallback, especially if there is no transforms available. Not all web.config files are environment specific or contain sensitive data. If there are transforms available and the default one is missing, an error might be more appropriate as you say. > > 4) An application can have multiple configs (sublevel web.configs or > splitted-out configs) which is not supported by the current implementation > (can add them through a component descriptor though). I suggest we handle > those in the same way? XDT applyable? Fallback? Yep - same way. Fallback if no transforms, transform if possible. - Brett -- Brett Porter [email protected] http://brettporter.wordpress.com/
