Embed the configuration settings in a dll

Topics: Exception Handling Application Block, Logging Application Block
Jan 6, 2009 at 9:39 PM
we have 4 websites and 6 console applications.....

It'd be nice if  I could just create a Logging.dll that has all the necessary configuration sections and information in it.
Because the configuration sections for the  logging and exception handling are going to be identical for all 10 applications and it's really annoying to have to duplicate that across 10 different config files...

It'd be nice if it just pulled those sections out of a config file embedded in Logging.dll

A few things I saw said that you could just use a Logging.dll.config  and the dll would know to check that.
But that didn't work for me. It still says cannot fine loggingSection

Thanks
Jan 7, 2009 at 6:34 AM
I haven't tried doing this yet but could you point me where did you find the suggestion you've tried so I could also try it out?


Sarah Urmeneta
Global Technology & Solutions
Avanade, Inc.
entlib.support@avanade.com
Jan 8, 2009 at 5:08 PM
Edited Jan 8, 2009 at 5:20 PM
New to codeplex and Enterprise Libraries possibilities, but... I want the same thing as the starting poster. Can I use the library to store application settings (user and application scoped) that are common to multiple apps, I have a similar requirement and want to implement a SettingsProvider provider (or get one for free) that will let me do this while still using the vanilla Visual Studio settings designer. I do not want to write my own provider and then find I break a roadmap rule in Windows Vista (and Win 7.0 for that matter). Tonnes of people must have the need for configuring an application suite in a simple yet flexible and robust (I read EntLib goals there) manner. :-)

With the exception of Entlib, nobody else seems to use a Designer anymore, am I wrong to not want to write lots of mucky code?
Jan 9, 2009 at 7:24 AM
I would just like to ask, is this something you want during development or deployment?  Cause if you just don't want to repeat the same configuration to different application, you could just use the configSource attribute.  For example,

<loggingConfiguration configSource="Config\Logging.config"/>

Using this approach, you can avoid writing extra codes in your application.


Sarah Urmeneta
Global Technology & Solutions
Avanade, Inc.
entlib.support@avanade.com
Jan 9, 2009 at 10:08 PM
Not sure that I understand the distinction between settings when developing and deployed really, although I want both.
The msdn documentation (one page only) indicates it is used for web services only, although I suspect it works for non-ASP too; but right now I am wanting to use the designer because it generates nice strongly typed properties for me, and does not seem to allow me to "include" another file.

The way System.Configuration works by default is to persist settings per Application, which is fine if you only have one really colossal process, but if you divide any system into smaller parts, and do not use a plug-in architecture because you want to offer for example 2 kinds of GUI, one normally has 2 or three applications which need to use the same values for a few settings.
It just feels like a real hack-job to override (implement) you own settingsprovider to do the job. Most apps want to have some kind of automatable settings console-app or tiny GUI which can be driven from the installer to initially customize, and from scripts to perform tasks such as backups. Writting you own settings provider to do exactly what the framework already does, but just in a multi-consumer pattern is not simple if you do not have time to learn about roaming, Vista security et-al.

Has anyone got a great pattern that lets me tie all (OK, not all, but a good few) of my settings to a common assembly, and not to the process? Because frankly that's the way we all did settings under Win32, Win16 and DOS for that matter, all in one config or registry file, or is there something the .NET Framework architects forgot to explain :-).
Jan 14, 2009 at 8:54 AM

You can use a common config file in EntLib by using the FileConfigurationSource.  Using Alternate Configuration Sources -> Using the File Configuration Source. 
The resulting config file will look something like this:

<configuration>

<
configSections>

 

<

section name="enterpriseLibrary.ConfigurationSource" type="Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ConfigurationSourceSection, Microsoft.Practices.EnterpriseLibrary.Common, Version=4.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

 

</

configSections>

 

<

enterpriseLibrary.ConfigurationSource selectedSource="File Configuration Source">

 

<

sources>

 

<

add name="File Configuration Source" type="Microsoft.Practices.EnterpriseLibrary.Common.Configuration.FileConfigurationSource, Microsoft.Practices.EnterpriseLibrary.Common, Version=4.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"

 

 

 

 

 

filePath="D:\Documents and Settings\sarah.b.urmeneta\My Documents\Visual Studio 2008\Projects\LoggingApp4.1\ConsoleApplication1\entlib.config" />

 

<

add name="System Configuration Source" type="Microsoft.Practices.EnterpriseLibrary.Common.Configuration.SystemConfigurationSource, Microsoft.Practices.EnterpriseLibrary.Common, Version=4.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

 

</

sources>

 

</

enterpriseLibrary.ConfigurationSource>

 

</

configuration>

 

 


Just take note that if you try to do the same thing again for another application, if you select the config file ("entlib.config") and click on Save, it will prompt you if you want to overwrite the file.  If you click yes, you will lose the settings you made there.  As a workaround, you could just copy and paste the <enterpriseLibrary.ConfigurationSource> section from your previous app or create a backup of the config file.

Sarah Urmeneta
Global Technology & Solutions
Avanade, Inc.
entlib.support@avanade.com

 

Feb 9, 2009 at 6:41 PM
cool I'll give that a try...
That should work for now to localize all the settings into one config file...

But it'd still be nice to do what conradb spoke of :)

Or even better it'd be nice if it worked how setting properties work...
Where it uses the settings parameters in the DLL unless they are overidden by the process... Which allows for a nice generalized, yet customizeable, foundation
Feb 9, 2009 at 8:00 PM
In searching around about the FileConfiguration I found this post
http://blogs.msdn.com/tomholl/archive/2006/04/02/entlib2externalconfig.aspx

Which is helpful cause you can just setup the ConfigurationSources yourself through Facade Classes in the DLL
Which is what I'm doing now