Hi guys, I have some thoughts to share around configuration for the new packaging implementations in NPanday 1.5.0: cloud service, dotnet application, msdeploy/web applications.
Sorry for the long e-mail, but that really is important for me as dev, coach, npanday contributor, and user :-) First, lets have a look at how Visual Studio handles the documentation for the various types: web.config / app.config Before Visual Studio 2008 one had to completely manually handle how the configuration is deployed onto other environments. I usually then deployed the config file initially only; after that i handled all changes to the configuration manually. In 2008 three new features are added that make this easier. 1) configuration can be split up in many files by using <theSection configurationFile=".."/> on any section. Then you can deploy most of the config every time and just handle environment-specific configs in separate files like connectionStrings.config++ 2) Config transforms (XDT); with right click on a web.config you can choose "Add Config Transforms" which will add a sub-file for each configuration in your Configuration Mangager, hence Web.Debug.config, Web.Release.config; those files are quite "intelligent" patch definitions applied to the main web.config on publish. By default this is only available for the main web.config, but not for sublevel web.configs nor for the app.config. 3) Parameters. Here you can define XPath-replacement-rules for various files; when unpacking/deploying a package with MSDeploy, by providing your environment-specific values for the defined parameters, the replacement will be applied to the files contained in the package. Sadly this is not integrated in Visual Studio, but has to be done manually. Azure Azure configurations consist of two parts: Cloud Service Definition (csdef) and Cloud Service Configuration (cscfg). The latter is meant to be environment-specific and Visual Studio allows you to configure multiple copies (Cloud, Local, ...). Csdef on the other hand is not (meant to be) environment specific and hence makes it into the Cloud Service Package (cspkg). Sadly in the UI it is not easy to see what config setting is stored where; however when turning on a specifc configuration (! ALL) some options will be disabled; these are the ones that go into the csdef: endpoints, vm size, ... NPanday 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. 2) For Azure, by default, ServiceConfiguration.Azure.cscfg is distributed; it is a COPY, not a transformation. Should we support transformation here? XDT, XSL? 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? 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? Happy for any thoughts/answers around this issue. _ Lars
