|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
External Config Filesapplications. I wrote a custom configSection handler and all that, and as long as the configSection lives in the app.config file everyone is happy. When I move the section out to separate file stored somewhere on the network, and reference it using the configSource="" attribute, the framework pukes and says "The configSource attribute must be a relative physical path." This is not very helpful at all. How are we supposed to reused common configuration information? When this common info changes, I don't want to have to chase down multiple config files and make multiple changes. What about code reuse and all that? This is really bumming me out. Does anyone have any suggestions how to make something like this work? Thanks Use a database.
-- Show quoteHTH, Kevin Spencer Microsoft MVP Printing Components, Email Components, FTP Client Classes, Enhanced Data Controls, much more. DSI PrintManager, Miradyne Component Libraries: http://www.miradyne.net "camainc" <cama***@gmail.com> wrote in message news:1176490891.319701.316400@l77g2000hsb.googlegroups.com... > I'm trying to share configuration information among several similar > applications. I wrote a custom configSection handler and all that, and > as long as the configSection lives in the app.config file everyone is > happy. > > When I move the section out to separate file stored somewhere on the > network, and reference it using the configSource="" attribute, the > framework pukes and says "The configSource attribute must be a > relative physical path." > > This is not very helpful at all. How are we supposed to reused common > configuration information? When this common info changes, I don't > want to have to chase down multiple config files and make multiple > changes. What about code reuse and all that? > > This is really bumming me out. Does anyone have any suggestions how to > make something like this work? > > Thanks >
Show quote
On 14 avr, 00:23, "Kevin Spencer" <unclechut***@nothinks.com> wrote: By the way, is it the standard behaviour of System.Configuration> Use a database. > > -- > HTH, > > Kevin Spencer > Microsoft MVP > > Printing Components, Email Components, > FTP Client Classes, Enhanced Data Controls, much more. > DSI PrintManager, Miradyne Component Libraries:http://www.miradyne.net > > "camainc" <cama***@gmail.com> wrote in message > > news:1176490891.319701.316400@l77g2000hsb.googlegroups.com... > > > I'm trying to share configuration information among several similar > > applications. I wrote a custom configSection handler and all that, and > > as long as the configSection lives in the app.config file everyone is > > happy. > > > When I move the section out to separate file stored somewhere on the > > network, and reference it using the configSource="" attribute, the > > framework pukes and says "The configSource attribute must be a > > relative physical path." > > > This is not very helpful at all. How are we supposed to reused common > > configuration information? When this common info changes, I don't > > want to have to chase down multiple config files and make multiple > > changes. What about code reuse and all that? > > > This is really bumming me out. Does anyone have any suggestions how to > > make something like this work? > > > Thanks generated files to be destroyed along with its application?
Show quote
On Apr 13, 5:34 pm, "Jouan Amate" <jouan.am***@gmail.com> wrote: Not that I know of.> On 14 avr, 00:23, "Kevin Spencer" <unclechut***@nothinks.com> wrote: > > > > > Use a database. > > > -- > > HTH, > > > Kevin Spencer > > Microsoft MVP > > > Printing Components, Email Components, > > FTP Client Classes, Enhanced Data Controls, much more. > > DSI PrintManager, Miradyne Component Libraries:http://www.miradyne.net > > > "camainc" <cama***@gmail.com> wrote in message > > >news:1176490891.319701.316400@l77g2000hsb.googlegroups.com... > > > > I'm trying to share configuration information among several similar > > > applications. I wrote a custom configSection handler and all that, and > > > as long as the configSection lives in the app.config file everyone is > > > happy. > > > > When I move the section out to separate file stored somewhere on the > > > network, and reference it using the configSource="" attribute, the > > > framework pukes and says "The configSource attribute must be a > > > relative physical path." > > > > This is not very helpful at all. How are we supposed to reused common > > > configuration information? When this common info changes, I don't > > > want to have to chase down multiple config files and make multiple > > > changes. What about code reuse and all that? > > > > This is really bumming me out. Does anyone have any suggestions how to > > > make something like this work? > > > > Thanks > > By the way, is it the standard behaviour of System.Configuration > generated files to be destroyed along with its application? On Apr 13, 5:23 pm, "Kevin Spencer" <unclechut***@nothinks.com> wrote: Kevin,> Use a database. > > -- > HTH, When I first read your reply, I thought you were joking or just being facetious. But then I thought that maybe you were being serious, so I decided to reply. Why would I use a database to store start-up configuration information, such as which database to use (dev, test or production), database connection strings, application start-up parameters, etc. etc.? Config files are for stuff that you need to know BEFORE your application starts up and connects to the database. I want to share common start-up information among several applications. As it is, if a database connection string changes, or a path to an external resource changes, or whatever, I have to change a bunch of config files, instead of just one or two shared config sections. Chuck I got tired of dinking with the config stuff in VS, and rolled my own. Mine
just reads from my own config file, which is simple XML, and loads the data into a dictionary, which is static and public to my app. If you want the users to share a config file, put it on a network drive, and use the UNC path to get to it. At some point, you're going to have to hard code the path to *some* file, unless you follow Kevin's direction and put the data in a database (which is a good idea, unless the database itself is one of the config settings, which makes that more difficult). If you use the UNC path, it doesn't matter what drive letter the users have it mapped to, or even if they *do* have it mapped, as long as they have read access to it. (I used this method for some apps with an Access backend. The users never saw the database, because they didn't have to map the drive.) If you want the users to each have their own config settings, stick it in Environment.SpecialFolder.LocalApplicationData, which on XP corresponds to c:\DocumentsAndSettings\userName\Local Settings\Application Data\. I actually add another folder for the name of my app to that path, and put all my user-specific stuff in there. The other benefit of this is when I reversion my app, I don't have to worry about losing the settings. Also, LocalApplicationData is an acceptable location to Vista, if you're looking forward. Good luck. Robin S. ----------------------------- Show quote "camainc" <cama***@gmail.com> wrote in message news:1176583504.411630.160550@e65g2000hsc.googlegroups.com... > On Apr 13, 5:23 pm, "Kevin Spencer" <unclechut***@nothinks.com> wrote: >> Use a database. >> >> -- >> HTH, > > Kevin, > > When I first read your reply, I thought you were joking or just being > facetious. But then I thought that maybe you were being serious, so I > decided to reply. > > Why would I use a database to store start-up configuration > information, such as which database to use (dev, test or production), > database connection strings, application start-up parameters, etc. > etc.? Config files are for stuff that you need to know BEFORE your > application starts up and connects to the database. > > I want to share common start-up information among several > applications. As it is, if a database connection string changes, or a > path to an external resource changes, or whatever, I have to change a > bunch of config files, instead of just one or two shared config > sections. > > Chuck > > Hi Chuck,
>Why would I use a database to store start-up configuration All you REALLY need before connecting to a database is it connection>information, such as which database to use (dev, test or production), >database connection strings, application start-up parameters, etc. >etc.? Config files are for stuff that you need to know BEFORE your >application starts up and connects to the database. string. Yes, that you'll need to store in a *.config file somewhere. Anything ELSE can really be stored in a "T_Configuration" table of some sorts. We switched from a plethora of web.config, app.config and all to a simple database-model, and it works just great. Now we can even use a simple ASP.NET page to look at and change our configuration on a remote system we don't have physical access to - works like a charm. Think about it ! Marc Hi Chuck,
Generically speaking, a database is simply a container for external data, just like a config file. The application must know something about the external resource in order to connect to it. This is also true of config files, for which the System.Configuration NameSpace and its members were created. The System.Data NameSpace was created for connecting to databases. The difference is that the .Net Application model is designed to recognize a local (to the AppDomain) config file without having to know anything about its location, since it is in the same AppDomain. To connect to any data source outside the AppDomain, whether it is a config file or a relational database, the application must know its' location. Thus, the Connection String. The point is, regardless of whether you "roll your own" configuration methodology, your app(s) will still have to store information locally (in a config file, perhaps?) about the location of the configuration data. -- Show quoteHTH, Kevin Spencer Microsoft MVP Printing Components, Email Components, FTP Client Classes, Enhanced Data Controls, much more. DSI PrintManager, Miradyne Component Libraries: http://www.miradyne.net "camainc" <cama***@gmail.com> wrote in message news:1176583504.411630.160550@e65g2000hsc.googlegroups.com... > On Apr 13, 5:23 pm, "Kevin Spencer" <unclechut***@nothinks.com> wrote: >> Use a database. >> >> -- >> HTH, > > Kevin, > > When I first read your reply, I thought you were joking or just being > facetious. But then I thought that maybe you were being serious, so I > decided to reply. > > Why would I use a database to store start-up configuration > information, such as which database to use (dev, test or production), > database connection strings, application start-up parameters, etc. > etc.? Config files are for stuff that you need to know BEFORE your > application starts up and connects to the database. > > I want to share common start-up information among several > applications. As it is, if a database connection string changes, or a > path to an external resource changes, or whatever, I have to change a > bunch of config files, instead of just one or two shared config > sections. > > Chuck > > > your app(s) will still have to store information locally (in a config Unless you use one of the Environment.SpecialFolder.* entries. Of course, > file, perhaps?) about the location of the configuration data. then it's hardcoded, but at least it's not hardcoded hardcoded. If you know what I mean. ;-) Robin S. ----------------------- Show quote "Kevin Spencer" <unclechut***@nothinks.com> wrote in message news:OqtCDNBgHHA.4704@TK2MSFTNGP06.phx.gbl... > Hi Chuck, > > Generically speaking, a database is simply a container for external data, > just like a config file. The application must know something about the > external resource in order to connect to it. This is also true of config > files, for which the System.Configuration NameSpace and its members were > created. The System.Data NameSpace was created for connecting to > databases. The difference is that the .Net Application model is designed > to recognize a local (to the AppDomain) config file without having to > know anything about its location, since it is in the same AppDomain. To > connect to any data source outside the AppDomain, whether it is a config > file or a relational database, the application must know its' location. > Thus, the Connection String. > > The point is, regardless of whether you "roll your own" configuration > methodology, your app(s) will still have to store information locally (in > a config file, perhaps?) about the location of the configuration data. > > -- > HTH, > > Kevin Spencer > Microsoft MVP > > Printing Components, Email Components, > FTP Client Classes, Enhanced Data Controls, much more. > DSI PrintManager, Miradyne Component Libraries: > http://www.miradyne.net > > "camainc" <cama***@gmail.com> wrote in message > news:1176583504.411630.160550@e65g2000hsc.googlegroups.com... >> On Apr 13, 5:23 pm, "Kevin Spencer" <unclechut***@nothinks.com> wrote: >>> Use a database. >>> >>> -- >>> HTH, >> >> Kevin, >> >> When I first read your reply, I thought you were joking or just being >> facetious. But then I thought that maybe you were being serious, so I >> decided to reply. >> >> Why would I use a database to store start-up configuration >> information, such as which database to use (dev, test or production), >> database connection strings, application start-up parameters, etc. >> etc.? Config files are for stuff that you need to know BEFORE your >> application starts up and connects to the database. >> >> I want to share common start-up information among several >> applications. As it is, if a database connection string changes, or a >> path to an external resource changes, or whatever, I have to change a >> bunch of config files, instead of just one or two shared config >> sections. >> >> Chuck >> >> > > Hello camainc,
1) You can create the config and add it to all project as the LINK among all project 2) You can use System.Xml namespace to read the content of config wherever it is --- WBR, Michael Nemtsev [.NET/C# MVP]. My blog: http://spaces.live.com/laflour Team blog: http://devkids.blogspot.com/ "The greatest danger for most of us is not that our aim is too high and we miss it, but that it is too low and we reach it" (c) Michelangelo c> I'm trying to share configuration information among several similar c> applications. I wrote a custom configSection handler and all that, c> and as long as the configSection lives in the app.config file c> everyone is happy. c> c> When I move the section out to separate file stored somewhere on the c> network, and reference it using the configSource="" attribute, the c> framework pukes and says "The configSource attribute must be a c> relative physical path." c> c> This is not very helpful at all. How are we supposed to reused common c> configuration information? When this common info changes, I don't c> want to have to chase down multiple config files and make multiple c> changes. What about code reuse and all that? c> c> This is really bumming me out. Does anyone have any suggestions how c> to make something like this work? c> c> Thanks c>
Show quote
On Apr 13, 9:01 pm, "camainc" <cama***@gmail.com> wrote: Hello:> I'm trying to share configuration information among several similar > applications. I wrote a custom configSection handler and all that, and > as long as the configSection lives in the app.config file everyone is > happy. > > When I move the section out to separate file stored somewhere on the > network, and reference it using the configSource="" attribute, the > framework pukes and says "The configSource attribute must be a > relative physical path." > > This is not very helpful at all. How are we supposed to reused common > configuration information? When this common info changes, I don't > want to have to chase down multiple config files and make multiple > changes. What about code reuse and all that? > > This is really bumming me out. Does anyone have any suggestions how to > make something like this work? > > Thanks Maybe this can help: http://nini.sourceforge.net/ Best regards. Oscar Acosta As Kevin says, .config files are really not a good way to share global
configuration information. One thing I've done a long time ago is build a configuration class that doesn't (but can) rely on the .NET configuration APIs and can write to a variety of stores. It also provides a strongly typed model that's portable across WinForm and Web apps. You can find article and code here: http://www.west-wind.com/presentations/configurationclass/configurationclass.asp One thing that this class will let you do once configured is switch configuration stores at will. So you can store in .config files, external (anywhere) XML files or to string or a database just by setting a few properties in the constructor of the component. If nothing else you might get some ideas on how to store data differently... Hope this helps, +++ Rick --- Show quote "camainc" <cama***@gmail.com> wrote in message news:1176490891.319701.316400@l77g2000hsb.googlegroups.com... > I'm trying to share configuration information among several similar > applications. I wrote a custom configSection handler and all that, and > as long as the configSection lives in the app.config file everyone is > happy. > > When I move the section out to separate file stored somewhere on the > network, and reference it using the configSource="" attribute, the > framework pukes and says "The configSource attribute must be a > relative physical path." > > This is not very helpful at all. How are we supposed to reused common > configuration information? When this common info changes, I don't > want to have to chase down multiple config files and make multiple > changes. What about code reuse and all that? > > This is really bumming me out. Does anyone have any suggestions how to > make something like this work? > > Thanks >  |
|||||||||||||||||||||||
Other interesting topics