|
web
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Config file for DLL??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 <aab***@yahoo.com> wrote in message Show quoteHide quote news:1161273903.758804.173270@b28g2000cwb.googlegroups.com... > 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. > If you don't want the settings to be changed per application, why are you
storing them in a configuration file? -- Show quoteHide quoteHTH, Kevin Spencer Microsoft MVP Chicken Salad Shooter http://unclechutney.blogspot.com A man, a plan, a canal, a palindrome that has.. oh, never mind. <aab***@yahoo.com> wrote in message news:1161273903.758804.173270@b28g2000cwb.googlegroups.com... > 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, 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. Show quoteHide quote "Kevin Spencer" <spam@uce.gov> wrote in message news:uViBVT88GHA.4604@TK2MSFTNGP03.phx.gbl... > 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. > > <aab***@yahoo.com> wrote in message > news:1161273903.758804.173270@b28g2000cwb.googlegroups.com... >> 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. >> > > How about using string resources in the DLL?
-- Show quoteHide quoteHTH, Kevin Spencer Microsoft MVP Short Order Coder http://unclechutney.blogspot.com What You Seek Is What You Get "Arthur Dent" <hitchhikersguideto-n***@yahoo.com> wrote in message news:C5A88D08-B4C4-4361-8C8D-8F5C99D0A588@microsoft.com... > 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. > > > > "Kevin Spencer" <spam@uce.gov> wrote in message > news:uViBVT88GHA.4604@TK2MSFTNGP03.phx.gbl... >> 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. >> >> <aab***@yahoo.com> wrote in message >> news:1161273903.758804.173270@b28g2000cwb.googlegroups.com... >>> 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. >>> >> >> 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/default.asp?url=/library/en-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... -- Patrice "Arthur Dent" <hitchhikersguideto-n***@yahoo.com> a écrit dans le message de news: C5A88D08-B4C4-4361-8C8D-8F5C99D0A***@microsoft.com...Show quoteHide quote > 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. > > > > "Kevin Spencer" <spam@uce.gov> wrote in message > news:uViBVT88GHA.4604@TK2MSFTNGP03.phx.gbl... >> 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. >> >> <aab***@yahoo.com> wrote in message >> news:1161273903.758804.173270@b28g2000cwb.googlegroups.com... >>> 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, 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 Show quoteHide quote "Patrice" <scr***@chez.com> wrote in message news:eiaTELF9GHA.4860@TK2MSFTNGP03.phx.gbl... > 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/default.asp?url=/library/en-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... > -- > Patrice > > "Arthur Dent" <hitchhikersguideto-n***@yahoo.com> a écrit dans le message > de news: C5A88D08-B4C4-4361-8C8D-8F5C99D0A***@microsoft.com... >> 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. >> >> >> >> "Kevin Spencer" <spam@uce.gov> wrote in message >> news:uViBVT88GHA.4604@TK2MSFTNGP03.phx.gbl... >>> 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. >>> >>> <aab***@yahoo.com> wrote in message >>> news:1161273903.758804.173270@b28g2000cwb.googlegroups.com... >>>> 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. >>>> >>> >>> > > 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... -- Patrice "Steve Long" <Steve_Noneya@NoSpam.com> a écrit dans le message de news: O$6$nsF9GHA.3***@TK2MSFTNGP03.phx.gbl...Show quoteHide quote > 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 > > "Patrice" <scr***@chez.com> wrote in message > news:eiaTELF9GHA.4860@TK2MSFTNGP03.phx.gbl... >> 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/default.asp?url=/library/en-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... >> -- >> Patrice >> >> "Arthur Dent" <hitchhikersguideto-n***@yahoo.com> a écrit dans le message >> de news: C5A88D08-B4C4-4361-8C8D-8F5C99D0A***@microsoft.com... >>> 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. >>> >>> >>> >>> "Kevin Spencer" <spam@uce.gov> wrote in message >>> news:uViBVT88GHA.4604@TK2MSFTNGP03.phx.gbl... >>>> 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. >>>> >>>> <aab***@yahoo.com> wrote in message >>>> news:1161273903.758804.173270@b28g2000cwb.googlegroups.com... >>>>> 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. >>>>> >>>> >>>> >> >> > > 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. Show quoteHide quote "Steve Long" <Steve_Noneya@NoSpam.com> wrote in message news:O$6$nsF9GHA.3348@TK2MSFTNGP03.phx.gbl... > 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 > > "Patrice" <scr***@chez.com> wrote in message > news:eiaTELF9GHA.4860@TK2MSFTNGP03.phx.gbl... >> 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/default.asp?url=/library/en-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... >> -- >> Patrice >> >> "Arthur Dent" <hitchhikersguideto-n***@yahoo.com> a écrit dans le message >> de news: C5A88D08-B4C4-4361-8C8D-8F5C99D0A***@microsoft.com... >>> 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. >>> >>> >>> >>> "Kevin Spencer" <spam@uce.gov> wrote in message >>> news:uViBVT88GHA.4604@TK2MSFTNGP03.phx.gbl... >>>> 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. >>>> >>>> <aab***@yahoo.com> wrote in message >>>> news:1161273903.758804.173270@b28g2000cwb.googlegroups.com... >>>>> 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. >>>>> >>>> >>>> >> >> > > 
Other interesting topics
Question about walking the file system
Show ToolTip on every Control continuously Searching desparately for createmailslot example in VB.NET (MSDN universal Subscriber) Starting process using shell execute returns nothing Transparent listview My.Settings wont update?? determining current winform application is active, has focus or being used Compressing textfiles, but still read them Upgrading a project, "Invalid Image" exception? |
|||||||||||||||||||||||
