Config file for DLL??

  • Thread starter Thread starter aabdis
  • Start date Start date
A

aabdis

Hello All....

I have a question... i have two Windows apps (one UI, and one service)
which use a common DLL that hands out database results and such to the
two apps. The DLL always connects to the DB the same way, regardless of
which app calls it. So i wanted to store info in the config file for
the DLL... only to find out it wont read that file at all. I am using
VS2005.

Searching online, i find that DLLs WILL NOT read their own configs, but
only of the exe which loaded them, and that basically, the only way to
store settings for the DLL itself, independent of the calling exe, is
to roll my own configuration/settings engine.

*Is that seriously true??* That seems a major flaw, as the whole point
of the DLL is to be common, and hide all the settings from the exes,
which is why i wanted it to have its own config file instead of having
to add the same settings over and over to every app that calls that
DLL.

Thanks in advance.
CheerZ.
 
Well, it's really not that difficult to roll your own configuration class. I
did for VS 2003 and continue to use it. If you consider it, the intrinsic
one is a bit limited anyway. You can even implement
IConfigurationSectionHandler. However, I didn't, I just rolled it from
scratch. It behaves very similarly to the instrinsic one but has more
capabilites.

Steve
 
If you don't want the settings to be changed per application, why are you
storing them in a configuration file?

--
HTH,

Kevin Spencer
Microsoft MVP
Chicken Salad Shooter
http://unclechutney.blogspot.com

A man, a plan, a canal, a palindrome that has.. oh, never mind.
 
Well, I want them to be easily and quickly changeable without having to
either recompile/redistribute or having to delve into the registry... that
is, a la "config file".

But I want them in <ONE> central place, that is, in the DLL.. the whole
point of the DLL is a central unit of shared "code". So that they do not
need to be changed in every application that uses the DLL. Some things
differ from app-to-app... but these settings are common to all apps and are
meant to be hidden in the DLL.

I have rolled the beginnings of my own configuration engine, as Steve did,
so its taken care of, it just seems strange is all.
 
Yes but it depends what your DLL does and someone else would want distinct
settings.

But I remember to have seen once that you can actually reference a config
file from within a config file. It would allow to accomodate both scenarios
:
- each application uses its own unique file, they have each their own
private settings
- if their config file references a single common config file, they can then
share those settings (all or just some of them)

After doing a small research I came accross :
http://msdn.microsoft.com/library/d...-us/cpgenref/html/gngrfAppSettingsElement.asp

The file attrribute seems to be the mechanism that references this common
file. You may want to give this a try...
 
Well, here's what I did.
I wrote an AppConfiguration dll. The AppInit class will take a path and
filename in its constructor. AppInit can handle any number of sections in
it. So:
<configuration>
<appSettings>
<add key="mynewkey" value="mynewvalue" />
<appSettings/>
<yetAnotherSection>
<add key="yetanotherkey" value="yetanothervalue" />
<yetAnotherSection/>
<configuration/>

AppInit reads in the above file in its proper hiearchy. To get the value for
"yetanotherkey", the code would be:

appInit.Get("sectionName", "yetanotherkey")

To get all the section names:
appInit.GetKeys()

To get all the keys for a particular section:
appInit.GetKeys("sectionName")

These both return a string array. And, because you can pass a fully
qualified filename to the constructor of AppInit, you can open any file with
it. The file name doesn't have to be myApp.exe.config. It could be a
completely different configuration file for different purposes, say a
..dll???
This is exactly what I do. I have configuration settings that are not
handled by the .exe but a .dll that the .exe uses.

AppInit also watches its file for changes and raises an event if the file
changes from some external source via a FileSystemWatcher.

I have a friend in the same industry as I am, that works at a different
place than me that took a similar approach to the configuration files
scenario, so my thinking wasn't too terribly screwed up... :)

Steve
 
I would likely still prefer the other approach if it works...

The entry point is the application config file but you can choose for each
setting if the value is specific to the application or given by a shared
configuration file...
 
This is very similar to what I did, though I took a little more technical
approach in terms of how the settings are referenced, using a path syntax
instead.

so for example my function looks like
GetSetting(Path as String, Optional DefaultValue as Object = Nothing) As
Object

It then uses XmlDocument.SelectSingleNode with that path, so that you can
store any level of sections/subsections/values hierarchy in the file.
Its still a baby of code, and not very robust yet, but like Steve's, it
takes in a filename, so you can pass it whatever file you want. Even have
multiple files for one project for different uses.
It will also have a version using SelectNodes() so that you can store
multiple settings with the same "key", that is, essentially a setting
collection, which the native App.Config files do not allow.
It works well enough.
 
Back
Top