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?

--
() ascii ribbon campaign - against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]

[Arne Vajhøj]

On 7/9/2020 6:58 AM, Anton Shepelev wrote:
> 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?

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]

Arne Vajhoj to 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.

[😉 Good Guy 😉]

On 09/07/2020 11:58, Anton Shepelev wrote:

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?

Would JSON file help?

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

--

With over 1.2 billion devices now running Windows 10, customer satisfaction is higher than any previous version of windows.

[Anton Shepelev]

Good Guy to 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.
> >
> > 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.

[Arne Vajhøj]

On 7/10/2020 10:49 AM, Anton Shepelev wrote:
> Arne Vajhoj to 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.

> 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.

>> 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.

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