So in this part we’re going to look at configuration parameters – parameters let you consolidate or seperate individual configuration parameters away from the components themselves, in this case we are going to create 2 config files, one for parameters to use in the live system, and the other for parameters in the debug system.
The advantage with this approach is that you don’t have to duplicate the component registrations, you can leave those in one place (for the example, we just put them in the app.config)… so lets start by looking at our two sets of property configurations…
And now the app.config…
Notice how the components configuration value has a hash (#) and some braces surrounding the word “configName” – that causes castle to look up the value of the property by the same name (which we declared in the property config file).
The application code is the same as part 4.
A common approach when working with developers who may need different configurations is to a file called say properties.config that contains all the configuration values that need to change between machines, and to not check that into source control… Be sure to also keep a “master” copy of the properties, say “master-properties.config” which provides a template for developers to create their own configuration (it’s not a bad place to stick the instructions for doing this as well).