Alternatives to app.config

[Anton Shepelev]

Hello, all

We have a program that uses a configuration file
written in our own custom syntax. In order for it
to work with different versions of a third-party as-
sembly, a colleague of mine was forced to employ the
app.config file. Now the program has two configura-
tion files, which is very poor design. Is there a
way to retrieve the same assembly binding informa-
tion from our own configuration file rather than
from app.config, provided that our config file is
read and processed before the reference to the
third-party assembly is resolved?

[Marcel Mueller]

Post by Anton Shepelev
We have a program that uses a configuration file
written in our own custom syntax. In order for it
to work with different versions of a third-party as-
sembly, a colleague of mine was forced to employ the
app.config file. Now the program has two configura-
tion files, which is very poor design. Is there a
way to retrieve the same assembly binding informa-
tion from our own configuration file rather than
from app.config, provided that our config file is
read and processed before the reference to the
third-party assembly is resolved?

I can't see the dependency of a third party assembly to your custom
configuration. You simply didn't nee app.config so far?

But having two config files is not that bad in general if these files
carry distinct types of information - e.g. runtime configuration versus
design time configuration. We often use this pattern. app.config
contains the technical part while the custom file contains the business
part.

Furthermore, unless you have runtime configuration in your app.config it
simply might be part of your deployment files and you do not need to
care much about its existence.

However, AFAIK you can modify the NameValueCollection behind
ConfigurationManager.AppSettings at run time. But be aware of timing
issues. Classes might access the settings in their static constructor
and it may be quite hard to prevent this constructors to run before your
code. This especially applies to the assembly loader as it likely runs
quite early.


Marcel

[Anton Shepelev]

We have a program that uses a configuration file
written in our own custom syntax. In order for it
to work with different versions of a third-party
asembly, a colleague of mine was forced to employ
the app.config file. Now the program has two con-
figuration files, which is very poor design. Is
there a way to retrieve the same assembly binding
information from our own configuration file rather
than from app.config, provided that our config
file is read and processed before the reference to
the third-party assembly is resolved?

I can't see the dependency of a third party assem-
bly to your custom configuration. You simply
didn't nee app.config so far?

We need app.config in order to specify the exact
version of a strongly-singed ADO.NET data provider,
because the version on the development machine usu-
ally differs.

But having two config files is not that bad in gen-
eral if these files carry distinct types of infor-
mation -- e.g. runtime configuration versus design
time configuration. We often use this pattern.
app.config contains the technical part while the
custom file contains the business part.

Well-said, but in our case app.config seems redun-
dant, for it is used only to redirect the version of
the data provider. I should be much happier if it
could automatically load the installed version with-
out manual interference.

Furthermore, unless you have runtime configuration
in your app.config it simply might be part of your
deployment files and you do not need to care much
about its existence.

In my case, the user/administrator must put into
this file the version of the data provider assembly
installed on the machine.

However, AFAIK you can modify the NameValueCollec-
tion behind ConfigurationManager.AppSettings at run
time. But be aware of timing issues. Classes
might access the settings in their static construc-
tor and it may be quite hard to prevent this con-
structors to run before your code. This especially
applies to the assembly loader as it likely runs
quite early.

Thanks, I will try it. I have a place in the code
that is executed as early as required.

[Arne Vajhøj]

Post by Anton Shepelev
We have a program that uses a configuration file
written in our own custom syntax. In order for it
to work with different versions of a third-party as-
sembly, a colleague of mine was forced to employ the
app.config file. Now the program has two configura-
tion files, which is very poor design. Is there a
way to retrieve the same assembly binding informa-
tion from our own configuration file rather than
from app.config, provided that our config file is
read and processed before the reference to the
third-party assembly is resolved?

Options must be:
1) Live with 2 config files.
2) Modify your own code to use standard app.config.
3) Somehow get information from your config file stuffed
into the Configuration used by the third party library.

I would probably chose #1 or #2, but that does not help you, so
let is assume #3.

I think the simplest solution would be to as the first thing
your code do it creates an app.config based in information
from your own config file. And you could even delete it
again when program exits.

I do not see any way of using the classic ConfigurationManager
to change assembly binding.

There are some new stuff ConfigurationBuilder, which I don't
know if it has anything useful.

But maybe you can avoid the Configuration. Some googling found:

https://blog.slaks.net/2013-12-25/redirecting-assembly-loads-at-runtime/

could that solve your problem?

Another possibility was instead of using assembly redirect to
use multiple app domains.

Arne

[Anton Shepelev]

But maybe you can avoid the Configuration. Some
https://blog.slaks.net/2013-12-25/redirecting-assembly-loads-at-runtime/

Looks good! I will try it.

[Anton Shepelev]

But maybe you can avoid the Configuration. Some
https://blog.slaks.net/2013-12-25/redirecting-assembly-loads-at-runtime/
could that solve your problem?

Unfortunately not. That mechanism fails with the
following error:

The located assembly's manifest definition does
not match the assembly reference.

Whereas all assemblies in GAC must be strongly
signed, I have no idea how that may work. Have you?