Avoiding .config files

[Anton Shepelev]

Hello, all

Do you know of a way to bypass app.config for such
problems as are generally solved by its modifica-
tion, e.g.:

https://www.spyriadis.net/2010/06/crystal-reports-framework-4-crdb_adoplus-dll/
(Banner alert!)

I for one hate these config files, written in cum-
bersome XML and integrated into the framework so
tightly that no code may be located and removed that
loads those files. The first thing that I do while
creating a new project is amputatate app.config. I
could tolerate an clean .ini file, but not XML.

It is very strange that .NET seems to insist on ev-
eryone's reliance on those config files without pro-
vision of alternative ways to achieve the same ef-
fect from code. Or am I wrong?

[Arne Vajhøj]

Post by Anton Shepelev
Do you know of a way to bypass app.config for such
problems as are generally solved by its modifica-
https://www.spyriadis.net/2010/06/crystal-reports-framework-4-crdb_adoplus-dll/
(Banner alert!)
I for one hate these config files, written in cum-
bersome XML and integrated into the framework so
tightly that no code may be located and removed that
loads those files. The first thing that I do while
creating a new project is amputatate app.config. I
could tolerate an clean .ini file, but not XML.
It is very strange that .NET seems to insist on ev-
eryone's reliance on those config files without pro-
vision of alternative ways to achieve the same ef-
fect from code. Or am I wrong?

I think a program app.config is way better than hiding the
config in the registry.

And XML is a lot more flexible than INI.

I don't think it is supported to override default
config mechanism.

But it is doable.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
<appSettings>
<add key="somekey" value="somevalue"/>
</appSettings>
</configuration>


using System;
using System.Collections.Specialized;
using System.Configuration;
using System.Configuration.Internal;
using System.Reflection;

namespace E
{
public class MyConfig : IInternalConfigSystem
{
public NameValueCollection appset;
public MyConfig()
{
appset = new NameValueCollection();
appset.Add("somekey", "someothervalue"); // this could come from
another file or from a database or from wherever
}
public object GetSection(string key)
{
if(key == "appSettings")
{
return appset;
}
else
{
return null;
}
}
public void RefreshConfig(string sectionName)
{
}
public bool SupportsUserConfig { get; private set; }
}
public class Program
{
public static void Main(string[] args)
{
Console.WriteLine(ConfigurationManager.AppSettings["somekey"]);
Type type = typeof(ConfigurationManager);
FieldInfo info = type.GetField("s_configSystem",
BindingFlags.NonPublic | BindingFlags.Static);
info.SetValue(null, new MyConfig());
Console.WriteLine(ConfigurationManager.AppSettings["somekey"]);
}
}
}

somevalue
someothervalue

Arne

[Anton Shepelev]

I for one hate these config files, written in
cumbersome XML and integrated into the framework
so tightly that no code may be located and re-
moved that loads those files. The first thing
that I do while creating a new project is ampu-
tatate app.config. I could tolerate an clean
.ini file, but not XML.

I think a program app.config is way better than
hiding the config in the registry.

I agree, but I never considered the registry as an
alternative. In my case, I need to define one sin-
gle hard-wired setting that is not going to be
changed during the program's lifetime.

And XML is a lot more flexible than INI.

Yes, but also clumsier and less readable. I should
avoid it at all costs whenever an INI file was suf-
ficient, which it is most of the time.

But it is doable.
[...]

Thanks for a working example! The configuration
that I need to override resides in the `startup'
section:

<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0"/>
</startup>

Will it not be too late to override it at the begin-
ning of the Main() method, because the `startup'
section will have been read and applied before entry
into Main()? The documentation is silent upon the
matter:

https://tinyurl.com/yazmwg6o
(<startup> element at Microsoft docs)

I believe I shall have to test it.

[Arne Vajhøj]

Post by Anton Shepelev

I for one hate these config files, written in
cumbersome XML and integrated into the framework
so tightly that no code may be located and re-
moved that loads those files. The first thing
that I do while creating a new project is ampu-
tatate app.config. I could tolerate an clean
.ini file, but not XML.

I think a program app.config is way better than
hiding the config in the registry.

I agree, but I never considered the registry as an
alternative.

A lot of pre-.NET applications used it as such.

Post by Anton Shepelev
In my case, I need to define one sin-
gle hard-wired setting that is not going to be
changed during the program's lifetime.

And XML is a lot more flexible than INI.

Yes, but also clumsier and less readable. I should
avoid it at all costs whenever an INI file was suf-
ficient, which it is most of the time.

XML, JSON, YAML etc. are all so common so people
should be able to work with them.

Post by Anton Shepelev

But it is doable.
[...]

Thanks for a working example! The configuration
that I need to override resides in the `startup'
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0"/>
</startup>
Will it not be too late to override it at the begin-
ning of the Main() method, because the `startup'
section will have been read and applied before entry
into Main()? The documentation is silent upon the
https://tinyurl.com/yazmwg6o
(<startup> element at Microsoft docs)
I believe I shall have to test it.

There could easily be a problem with that, because
the .NET runtime is started when the code is executing
and it is a bit hard to step backwards and reactivate the
runtime.

But I don't see the problem with that. It is config
of the runtime not of the application.

Arne

[😉 Good Guy 😉]

Post by Anton Shepelev
Hello, all
Do you know of a way to bypass app.config for such
problems as are generally solved by its modifica-
https://www.spyriadis.net/2010/06/crystal-reports-framework-4-crdb_adoplus-dll/
(Banner alert!)
I for one hate these config files, written in cum-
bersome XML and integrated into the framework so
tightly that no code may be located and removed that
loads those files. The first thing that I do while
creating a new project is amputatate app.config. I
could tolerate an clean .ini file, but not XML.
It is very strange that .NET seems to insist on ev-
eryone's reliance on those config files without pro-
vision of alternative ways to achieve the same ef-
fect from code. Or am I wrong?

Would JSON file help?

<https://docs.microsoft.com/en-us/aspnet/core/fundamentals/configuration/?view=aspnetcore-3.1>

[Anton Shepelev]

Post by 😉 Good Guy 😉

I for one hate these config files, written in
cumbersome XML and integrated into the framework
so tightly that no code may be located and re-
moved that loads those files. The first thing
that I do while creating a new project is ampu-
tatate app.config. I could tolerate an clean
.ini file, but not XML.
It is very strange that .NET seems to insist on
everyone's reliance on those config files with-
out pro vision of alternative ways to achieve
the same effect from code. Or am I wrong?

Would JSON file help?

Thanks, I did not know JSON was supported for .NET
config files, but it helps only partially. My other
criticisms include the super-tight integration of
the config files with .NET instead of letting the
programmer to load the standard config file via an
explicit invocation if desired, and the lack of al-
ternative configuation methods.

From time to time I find solutions to problems that
involve modification of .config files, but in my
case the majority of those modifications are not to
be touched by users, administrators, or programmers.
I should prefer to have those settings in my code
rather than in the modifiable .config file that has
to be distributed together with the program. It is a
burden and a vulnerability.