 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / CLR / October 2006DLL configuration files
Does anyone know how to access settings in a DLL's config file? Say you have a DLL that stores some connection string information in it's config file. The DLL also has some method to make use of that stored value (like Connect()). So if the DLL is then late bound by an EXE, how does the Connect method access the stored value? ConfigurationManager.ConnectionStrings["SomeKeyName"] will not do it since it references the EXE's configuration file. In the case when and EXE will be loading an undetermined list of DLL's (aka plug-ins) and one cannot anticipate what to put in the EXE's configuration file to support the DLL's requirements, is there not a means of the DLL Connect method accessing its own configuration file? It is after all in the output folder as "latebounddll.dll.config" right alongside the "myexe.exe.config". Thx Ok, I stumbled my way through a means of doing this. It's not elegant but here goes... string connectionString = ConfigurationManager.OpenExeConfiguration(System.Reflection.Assembly.GetExecutingAssembly().Location).ConnectionStrings.ConnectionStrings["SomeKeyName"].ConnectionString; The OpenExeConfiguration apparently works also for DLL's. Though I would have preferred to have seen something akin to ConfigurationManager.LocalConfiguration or ConfigurationManager.Current in the Framework that would have returned either null or access to the DLL's corresponding configuration file. Access to the EXE's configuration is already available through other properties of the ConfigurationManager class. Hello md, DONT DO THIS. DLLs should NOT have config files.. EVER. If your function needs a parameter, have the calling application pass it in. DLLs should be self-contained, only accepting inputs via the publicly exposed interface. -Boo > Does anyone know how to access settings in a DLL's config file? Say > you have a DLL that stores some connection string information in it's [quoted text clipped - 13 lines] > > Thx > Hello md, > > DONT DO THIS. DLLs should NOT have config files.. EVER. If your > function needs a parameter, have the calling application pass it in. > DLLs should be self-contained, only accepting inputs via the publicly > exposed interface. Well, let's consider the following scenario. You have a GUI application that allows you to choose which implementation you want. A or B. If A is chosen, then the app will load A.DLL; If B is chosen, then the app will load B.DLL; The app interacts with the implementation via an interface, IWhoCares: IWhoCares.doSomething(); Now, A and B implement the interface in very different ways so that A and B require very different configuration parameters to make themselves work. Since the app is not interested in how the implementation works, why should the app send the parameters required by either A or B down to the implementation DLL? Also, what if implementation C is introduced later and C requires another different set of configuration parameters? Why do the configuration parameters private to respective implementations have to be passed from the caller app?  SignaturePeter Wu Powered by Gentoo GNU/Linux 2.6.17 Yes Peter, that is the exact scenario I am facing. I have an application that loads plug-ins over ClickOnce deployment, all of which already adhere to a contract, i.e. interface, but indeed have varying prerequisites as far as parameters that are not only required but also need to be configurable individually. Interestingly, one can use the pre-canned settings file available in a C# project that in essence auto-generates a static class that contains the key/value pairs. The class exposes the values as properties of the static class. An entry is automatically placed within the app.config file where the end-user can override them. This is a nice approach because from the code side one gets type safety and can rely on Intellisense to state something like: string s = Settings.Default.MyKeyName; So in self reflection, this may be a cleaner approach than my first stab -- and likely the intended approach by the Visual Studio development team. -- Thx Boo, I guess NHibernate, log4net, NLog, etc. didn't get the memo. Even a lot of the System.*.dll assemblies read the app.config file. Brian > Hello md, > [quoted text clipped - 22 lines] > > > > Thx Hello Brian, Yes.. like System.Configuration.. imagine that. -Boo > Boo, > [quoted text clipped - 30 lines] >>> >>> Thx > Hello Brian, > [quoted text clipped - 8 lines] > > > > Brian Here are a few more that I know of off the top of my head. System.Runtime.Remoting.dll System.ServiceModel.dll System.Transactions.dll System.Workflow.Runtime.dll Brian > DONT DO THIS. DLLs should NOT have config files.. EVER. If your function > needs a parameter, have the calling application pass it in. > DLLs should be self-contained, only accepting inputs via the publicly > exposed interface. Boo, I have an app that can load different storage engines as plugins. These storage engines can store it's data in any type of file, a database, getting the data from a php page etc. The main app doesn't know (or care) how the data is stored and retrieved, the plugins only need to implement a specific interface that has open, save etc methods. Do you really mean that the best solution for persisting plugin specific settings (for example, the connection string for a database or the path to the last saved xml file) is for the main app to handle it? Wouldn't that mean that the app has to know each plugins needs up front and for me as a programmer to anticipate any future storage engines requirements? Do you have a smarter, more flexible solution to this problem that I haven't thought of? SignatureRegards, Peter > Hello md, > [quoted text clipped - 15 lines] >> >> Thx Hello Peter, A feedback system whereby the DLL passes the settings back to the main app for storage and retreval. DLLs should not, ever, have config files. -Boo >> DONT DO THIS. DLLs should NOT have config files.. EVER. If your >> function [quoted text clipped - 37 lines] >>> >>> Thx > Hello Peter, > > A feedback system whereby the DLL passes the settings back to the main > app for storage and retreval. Can you please give me some code snippet that can address the scenario I put forward in my response to your message the other day? If the caller app is not aware of/not interested in how the implementations work, how can the caller app handle the "feedback"? > DLLs should not, ever, have config files. Can you shed some light on this? Or point us to some books or articles that support your view? SignaturePeter Wu Powered by Gentoo GNU/Linux 2.6.17 > A feedback system whereby the DLL passes the settings back to the main app > for storage and retreval. If I understand you correctly, you mean something like this: public interface IAppInterface { ... public void LoadPluginSettings(string PluginName, out string [] Settings); public void SavePluginSettings(string PluginName, string [] Settings); } IAppInterface is of course accessible from the plugin(s). I realize that this might not be exactly what you mean, but maybe close? SignatureRegards, Peter >> A feedback system whereby the DLL passes the settings back to the main >> app for storage and retreval. [quoted text clipped - 11 lines] > IAppInterface is of course accessible from the plugin(s). I realize that > this might not be exactly what you mean, but maybe close? This has been around for a few years before .NET. The application is supposed to pass a "PropertyBag" to each component it instantiates which the component can customize for its needs, cache user settings, etc. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.