Handling configuration when packaging with NPanday

[Lars Corneliussen <me...@lcorneliussen.de>]

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

Re: Handling configuration when packaging with NPanday

[Brett Porter <br...@apache.org>]

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
brett@apache.org
http://brettporter.wordpress.com/