How to use ConfigurationSection

[Guest]

Currently, we are storing our application settings in the registry, but we
want them to be stored in config-files. In order to accomplish that I'm using
the .NET 2.0 System.Configuration namespace. A couple of my own configuration
class have already been derived from ConfigurationSection;
ConfigurationProperty attributes have been added to the the properties as
well. This all works very well, but I forsee some problems for the future:

Question1: In release 1 (R1) configuration property 1 (P1) is available. In
release 2 (R2) P1 is not required anymore and gets removed. When R2 tries to
read the config-file it encounters P1 and throws an exception because it
isn't defined anymore. How can I resolve this, without reconfiguring the
application?

Some of assemblies are registered for com-interop and need to be installed
in the GAC. When assemblies are installed in the GAC, the full name
(including version number) needs to be entered in the config-file in the
attribute "/configuration/configSections/section@type".

Question 2: The first release (R1) has version number 1.0.0.0 and the
section defined in the config-file refers to version 1.0.0.0. The next
release (R2) with version number 2.0.0.0 is installed. The config-file stays
unchanged, because the configurations must be kept. When R2 loads the
configuration an exception is thrown with the message that the assembly with
version 1.0.0.0 couldn't be found. How can I upgrade the configuration from
R1 to R2?

Thanks in advance,
Edwin

 

[Adrian Parker]

Because of the problem with assembly versions etc in the web.config, we
moved all of our application settings to a settings.config file instead so
that we could change and distribute a new web.config as we like.

We created an external windows app to maintain the settings in the config
files, and it checks a version number in the file to clear out old settings
as necessary. The web app will not run until the version in the config file
matches the software version.

| Currently, we are storing our application settings in the registry, but we
| want them to be stored in config-files. In order to accomplish that I'm
using
| the .NET 2.0 System.Configuration namespace. A couple of my own
configuration
| class have already been derived from ConfigurationSection;
| ConfigurationProperty attributes have been added to the the properties as
| well. This all works very well, but I forsee some problems for the future:
|
| Question1: In release 1 (R1) configuration property 1 (P1) is available.
In
| release 2 (R2) P1 is not required anymore and gets removed. When R2 tries
to
| read the config-file it encounters P1 and throws an exception because it
| isn't defined anymore. How can I resolve this, without reconfiguring the
| application?
|
| Some of assemblies are registered for com-interop and need to be installed
| in the GAC. When assemblies are installed in the GAC, the full name
| (including version number) needs to be entered in the config-file in the
| attribute "/configuration/configSections/section@type".
|
| Question 2: The first release (R1) has version number 1.0.0.0 and the
| section defined in the config-file refers to version 1.0.0.0. The next
| release (R2) with version number 2.0.0.0 is installed. The config-file
stays
| unchanged, because the configurations must be kept. When R2 loads the
| configuration an exception is thrown with the message that the assembly
with
| version 1.0.0.0 couldn't be found. How can I upgrade the configuration
from
| R1 to R2?
|
| Thanks in advance,
| Edwin

 

[Guest]

Our application is a windows app. I am already using my own config file that
I distribute with the setup. It can be modified using another app.
You said: "so that we could change and distribute a new web.config as we
like". Because a lot settings are user-specific (a com-port for example) I
cannot distribute new settings.

Both questions remain open.

 

[Dave Sexton]

Hi Edwin,

I believe Adrian was referring to Application Settings in the 2.0 framework.

Application Settings on MSDN:
http://msdn2.microsoft.com/en-us/library/k4s6c3a0.aspx

They provide user or application-level settings that can be stored outside of
your application's .config file.

If you don't find this option to be feasible, I'm posting alternatives in
another response.

 

[Dave Sexton]

Hi Edwin,

Currently, we are storing our application settings in the registry, but we
want them to be stored in config-files. In order to accomplish that I'm
using
the .NET 2.0 System.Configuration namespace. A couple of my own
configuration
class have already been derived from ConfigurationSection;
ConfigurationProperty attributes have been added to the the properties as
well. This all works very well, but I forsee some problems for the future:

Question1: In release 1 (R1) configuration property 1 (P1) is available. In
release 2 (R2) P1 is not required anymore and gets removed. When R2 tries to
read the config-file it encounters P1 and throws an exception because it
isn't defined anymore. How can I resolve this, without reconfiguring the
application?

If you are changing the way your application can be configured in code then
you will naturally have to change the actual configuration as well. What your
asking is essentially the same as, "How can I use a configuration file
designed for one application, in another?". You can't unless they are 100%
compatible.

If you want to automate the reconfiguration of subsequent versions of your
application you could try creating a custom installer for your setup project
that reads existing .config files and imports relevant sections and values
into the supported versions. You should also try to supply appropriate
defaults, of course.

Some of assemblies are registered for com-interop and need to be installed
in the GAC. When assemblies are installed in the GAC, the full name
(including version number) needs to be entered in the config-file in the
attribute "/configuration/configSections/section@type".

If you need to bind to the specific version of a GACed assembly you can use
binding redirection in a publisher policy. Then, you can simply specify the
Type and Assembly name in configuration.

Binding Redirection on MSDN:
http://msdn2.microsoft.com/en-us/library/2fc472t2.aspx

Of course, you can also use the other approach I mentioned, which is to update
the assembly names for subsequent versions using a custom installer.

Question 2: The first release (R1) has version number 1.0.0.0 and the
section defined in the config-file refers to version 1.0.0.0. The next
release (R2) with version number 2.0.0.0 is installed. The config-file stays
unchanged, because the configurations must be kept. When R2 loads the
configuration an exception is thrown with the message that the assembly with
version 1.0.0.0 couldn't be found. How can I upgrade the configuration from
R1 to R2?

I'm not sure what you mean here. Isn't this question the same as the one
above?

 

[Guest]

Thanks, I know enough now.

Hi Edwin,



If you are changing the way your application can be configured in code then
you will naturally have to change the actual configuration as well. What your
asking is essentially the same as, "How can I use a configuration file
designed for one application, in another?". You can't unless they are 100%
compatible.

If you want to automate the reconfiguration of subsequent versions of your
application you could try creating a custom installer for your setup project
that reads existing .config files and imports relevant sections and values
into the supported versions. You should also try to supply appropriate
defaults, of course.


If you need to bind to the specific version of a GACed assembly you can use
binding redirection in a publisher policy. Then, you can simply specify the
Type and Assembly name in configuration.

Binding Redirection on MSDN:
http://msdn2.microsoft.com/en-us/library/2fc472t2.aspx

Of course, you can also use the other approach I mentioned, which is to update
the assembly names for subsequent versions using a custom installer.


I'm not sure what you mean here. Isn't this question the same as the one
above?