views:

39

answers:

2

We have a fairly hefty VS2008 solution that comprises of many library projects that are referenced by one or more other projects. Some of these libraries define things like WCF bindings and connection strings, but when these are referenced by other projects, it seems to become a necessity to copy the binding settings from the library projects' .config files into the executable projects. It seems like we're missing something here as this approach has started to violate DRY principals in a major way with duplicate settings littered throughout the solution. Changing a binding has become a major exercise in search & replace.

I have looked at the this project on CodePlex as a possible solution, but I wonder if we're misunderstanding the principals behind app/web.config files.

Is there an easier way?

+1  A: 

Not really no.

In sufficiently large projects you end up with settings that need to go in several projects.

One solution I've used previously is to have a custom task run on post-build to modify the configs to set a specific variable (say '$generalSettings') with a bunch on common things, from a local file I call 'local.deploy.properties'. I use NAnt to do this.

These days, I use a custom solution I've written to do it (though it combines the approach above anyway, due to the need to test locally).

Anyway, what I'm getting at is this is a generally unsolved problem.

Noon Silk
+1  A: 

You have to automate settings propagation in order to keep things working properly. This can be done by adding batch copy command in post-build actions. You can find this settings in the project properties menu. In order to customize copied settings for a specific project the XSLT transform can be used.

Jenea