|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Proper place for custom CONFIG fileWe have a set of applications and assemblies that belong to one project. Some of the configuration settings are supposed to be shared between various assemblies on the same machine. After long discussions we finally decided that the best alternative for us is to create a custom configuration file <OutProject>.config and place it in a common directory. Then we can write our own configuration parser that will return NameValueCollection settings. There seems to be two good places to install such file: <Windows>\Microsoft.NET\Framework\<CurrentVersion> and <Windows>\Microsoft.NET\Framework\<CurrentVersion>\CONFIG. Both of them contain several configuration files. My first impression was that the latter one is the best (since it's called CONFIG), however it contains only system specific configurations files like machine.config. All application-based config files are located one level up, inside <Windows>\Microsoft.NET\Framework\<CurrentVersion>. Do you know what is the best practice? Thanks Vagif Abilov Contopronto AS Oslo Norway >We have a set of applications and assemblies that belong to one project. Yes - but those are system directories - I'd stay away from those if>There seems to be two good places to install such file: ><Windows>\Microsoft.NET\Framework\<CurrentVersion> and ><Windows>\Microsoft.NET\Framework\<CurrentVersion>\CONFIG. Both of them >contain several configuration files. ever possible! >Do you know what is the best practice? If I were you, and I had a bunch of applications for a given project,I'd put all of those into a specific directory, e.g. c:\program files\myApp, and put common config files there, too. Stay out of system directories if you ever can! Marc ================================================================ Marc Scheuner May The Source Be With You! Berne, Switzerland m.scheuner -at- inova.ch Thanks Marc, I see your point. However, I am not sure I fully share it.
Microsoft lists Machine.Config as one of the potential places to add global configuration information (althouth they recommend to think twice before adding your own stuff there). Putting your own file in that directory is surely a better option than writing directly into Machine.config. On the other hand, if I select some other place to place config file, I need to agree about some common shared folder. In my case it's not just one application. It's a series of appications and subprojects from them same company that are installed using different installers and folders, some of them are Web applications, others are regular Windows applications. To me using one of Framework directories in such case is not that bad comparing to hard-coding another folder name. Just my 2 cents. Vagif Show quoteHide quote "Marc Scheuner [MVP ADSI]" <m.scheuner@inova.SPAMBEGONE.ch> wrote in message news:ok4nt094jndl3btno24rdnj8gki8sf7emg@4ax.com... > >We have a set of applications and assemblies that belong to one project. >>There seems to be two good places to install such file: >><Windows>\Microsoft.NET\Framework\<CurrentVersion> and >><Windows>\Microsoft.NET\Framework\<CurrentVersion>\CONFIG. Both of them >>contain several configuration files. > > Yes - but those are system directories - I'd stay away from those if > ever possible! > >>Do you know what is the best practice? > > If I were you, and I had a bunch of applications for a given project, > I'd put all of those into a specific directory, e.g. c:\program > files\myApp, and put common config files there, too. > > Stay out of system directories if you ever can! > > Marc > ================================================================ > Marc Scheuner May The Source Be With You! > Berne, Switzerland m.scheuner -at- inova.ch I blogged this point recently. Perhaps this will help:
http://blogs.msdn.com/nickmalik/archive/2004/11/25/270420.aspx -- Show quoteHide quote--- Nick Malik [Microsoft] MCSD, CFPS, Certified Scrummaster http://blogs.msdn.com/nickmalik Disclaimer: Opinions expressed in this forum are my own, and not representative of my employer. I do not answer questions on behalf of my employer. I'm just a programmer helping programmers. -- "Vagif Abilov" <va***@online.no> wrote in message news:%23qlMrwv8EHA.2156@TK2MSFTNGP10.phx.gbl... > Thanks Marc, I see your point. However, I am not sure I fully share it. > Microsoft lists Machine.Config as one of the potential places to add global > configuration information (althouth they recommend to think twice before > adding your own stuff there). Putting your own file in that directory is > surely a better option than writing directly into Machine.config. On the > other hand, if I select some other place to place config file, I need to > agree about some common shared folder. In my case it's not just one > application. It's a series of appications and subprojects from them same > company that are installed using different installers and folders, some of > them are Web applications, others are regular Windows applications. To me > using one of Framework directories in such case is not that bad comparing to > hard-coding another folder name. > > Just my 2 cents. > > Vagif > > > "Marc Scheuner [MVP ADSI]" <m.scheuner@inova.SPAMBEGONE.ch> wrote in message > news:ok4nt094jndl3btno24rdnj8gki8sf7emg@4ax.com... > > >We have a set of applications and assemblies that belong to one project. > >>There seems to be two good places to install such file: > >><Windows>\Microsoft.NET\Framework\<CurrentVersion> and > >><Windows>\Microsoft.NET\Framework\<CurrentVersion>\CONFIG. Both of them > >>contain several configuration files. > > > > Yes - but those are system directories - I'd stay away from those if > > ever possible! > > > >>Do you know what is the best practice? > > > > If I were you, and I had a bunch of applications for a given project, > > I'd put all of those into a specific directory, e.g. c:\program > > files\myApp, and put common config files there, too. > > > > Stay out of system directories if you ever can! > > > > Marc > > ================================================================ > > Marc Scheuner May The Source Be With You! > > Berne, Switzerland m.scheuner -at- inova.ch > > Thanks Nick, there's not much discussion of such things int MSDN articles,
so your blog definitely a good help. Vagif "Nick Malik [Microsoft]" <nickmalik@hotmail.nospam.com> wrote in message news:DMNCd.75542$k25.15421@attbi_s53...Show quoteHide quote >I blogged this point recently. Perhaps this will help: > http://blogs.msdn.com/nickmalik/archive/2004/11/25/270420.aspx > > > -- > --- Nick Malik [Microsoft] > MCSD, CFPS, Certified Scrummaster > http://blogs.msdn.com/nickmalik > > Disclaimer: Opinions expressed in this forum are my own, and not > representative of my employer. > I do not answer questions on behalf of my employer. I'm just a > programmer helping programmers. > -- > "Vagif Abilov" <va***@online.no> wrote in message > news:%23qlMrwv8EHA.2156@TK2MSFTNGP10.phx.gbl... >> Thanks Marc, I see your point. However, I am not sure I fully share it. >> Microsoft lists Machine.Config as one of the potential places to add > global >> configuration information (althouth they recommend to think twice before >> adding your own stuff there). Putting your own file in that directory is >> surely a better option than writing directly into Machine.config. On the >> other hand, if I select some other place to place config file, I need to >> agree about some common shared folder. In my case it's not just one >> application. It's a series of appications and subprojects from them same >> company that are installed using different installers and folders, some >> of >> them are Web applications, others are regular Windows applications. To me >> using one of Framework directories in such case is not that bad comparing > to >> hard-coding another folder name. >> >> Just my 2 cents. >> >> Vagif >> >> >> "Marc Scheuner [MVP ADSI]" <m.scheuner@inova.SPAMBEGONE.ch> wrote in > message >> news:ok4nt094jndl3btno24rdnj8gki8sf7emg@4ax.com... >> > >We have a set of applications and assemblies that belong to one > project. >> >>There seems to be two good places to install such file: >> >><Windows>\Microsoft.NET\Framework\<CurrentVersion> and >> >><Windows>\Microsoft.NET\Framework\<CurrentVersion>\CONFIG. Both of them >> >>contain several configuration files. >> > >> > Yes - but those are system directories - I'd stay away from those if >> > ever possible! >> > >> >>Do you know what is the best practice? >> > >> > If I were you, and I had a bunch of applications for a given project, >> > I'd put all of those into a specific directory, e.g. c:\program >> > files\myApp, and put common config files there, too. >> > >> > Stay out of system directories if you ever can! >> > >> > Marc >> > ================================================================ >> > Marc Scheuner May The Source Be With You! >> > Berne, Switzerland m.scheuner -at- inova.ch >> >> > > Hi,
I agree with marc. What about if there is allready a config file with the same name than yours in a directories that you can't control ? you can erase it, or yours can be erase by error ... I have the same problematic than you, vagif. To work around this i put my config file in the My c:\Program Files\MyCompany\Config\ . I reference it in the registry, with the complete path. I think the place where it is has no importance, it is just important to be sure to found it when necessary. (You must also have to set the config file to be not uninstallable when the first application you install is uninstalled.) Hope i help. ROM www.maintag.com "Vagif Abilov" <va***@online.no> a écrit dans le message de news: %23qlMrwv8EHA.2***@TK2MSFTNGP10.phx.gbl...Show quoteHide quote > Thanks Marc, I see your point. However, I am not sure I fully share it. > Microsoft lists Machine.Config as one of the potential places to add > global configuration information (althouth they recommend to think twice > before adding your own stuff there). Putting your own file in that > directory is surely a better option than writing directly into > Machine.config. On the other hand, if I select some other place to place > config file, I need to agree about some common shared folder. In my case > it's not just one application. It's a series of appications and > subprojects from them same company that are installed using different > installers and folders, some of them are Web applications, others are > regular Windows applications. To me using one of Framework directories in > such case is not that bad comparing to hard-coding another folder name. > > Just my 2 cents. > > Vagif > > > "Marc Scheuner [MVP ADSI]" <m.scheuner@inova.SPAMBEGONE.ch> wrote in > message news:ok4nt094jndl3btno24rdnj8gki8sf7emg@4ax.com... >> >We have a set of applications and assemblies that belong to one project. >>>There seems to be two good places to install such file: >>><Windows>\Microsoft.NET\Framework\<CurrentVersion> and >>><Windows>\Microsoft.NET\Framework\<CurrentVersion>\CONFIG. Both of them >>>contain several configuration files. >> >> Yes - but those are system directories - I'd stay away from those if >> ever possible! >> >>>Do you know what is the best practice? >> >> If I were you, and I had a bunch of applications for a given project, >> I'd put all of those into a specific directory, e.g. c:\program >> files\myApp, and put common config files there, too. >> >> Stay out of system directories if you ever can! >> >> Marc >> ================================================================ >> Marc Scheuner May The Source Be With You! >> Berne, Switzerland m.scheuner -at- inova.ch > > Romain,
Thank you for the suggestion. I am _alsmost_ convinced now that I should not place my config files under .NET framework catalog. However I am not sure about Program Files\My Company either. Program File directory lists individual application folders, and we need a place for our shared files (shared between different applications and Web sites). There is another folder called "Common Files" (under Program Files) where various Companies store their data (available in .NET, System.Environment.SpecialFolder.CommonProgramFiles). I am thinking of using this one. Vagif Show quoteHide quote "Romain TAILLANDIER" <RomainDotTaillandier_nospam@MaintagDotCom_remove> wrote in message news:%23JNOTWw8EHA.3124@TK2MSFTNGP11.phx.gbl... > Hi, > > I agree with marc. > What about if there is allready a config file with the same name than > yours in a directories that you can't control ? you can erase it, or yours > can be erase by error ... > > I have the same problematic than you, vagif. > To work around this i put my config file in the My c:\Program > Files\MyCompany\Config\ . I reference it in the registry, with the > complete path. I think the place where it is has no importance, it is just > important to be sure to found it when necessary. > > (You must also have to set the config file to be not uninstallable when > the first application you install is uninstalled.) > > Hope i help. > > > ROM > www.maintag.com > > > > "Vagif Abilov" <va***@online.no> a écrit dans le message de news: > %23qlMrwv8EHA.2***@TK2MSFTNGP10.phx.gbl... >> Thanks Marc, I see your point. However, I am not sure I fully share it. >> Microsoft lists Machine.Config as one of the potential places to add >> global configuration information (althouth they recommend to think twice >> before adding your own stuff there). Putting your own file in that >> directory is surely a better option than writing directly into >> Machine.config. On the other hand, if I select some other place to place >> config file, I need to agree about some common shared folder. In my case >> it's not just one application. It's a series of appications and >> subprojects from them same company that are installed using different >> installers and folders, some of them are Web applications, others are >> regular Windows applications. To me using one of Framework directories in >> such case is not that bad comparing to hard-coding another folder name. >> >> Just my 2 cents. >> >> Vagif >> >> >> "Marc Scheuner [MVP ADSI]" <m.scheuner@inova.SPAMBEGONE.ch> wrote in >> message news:ok4nt094jndl3btno24rdnj8gki8sf7emg@4ax.com... >>> >We have a set of applications and assemblies that belong to one >>> >project. >>>>There seems to be two good places to install such file: >>>><Windows>\Microsoft.NET\Framework\<CurrentVersion> and >>>><Windows>\Microsoft.NET\Framework\<CurrentVersion>\CONFIG. Both of them >>>>contain several configuration files. >>> >>> Yes - but those are system directories - I'd stay away from those if >>> ever possible! >>> >>>>Do you know what is the best practice? >>> >>> If I were you, and I had a bunch of applications for a given project, >>> I'd put all of those into a specific directory, e.g. c:\program >>> files\myApp, and put common config files there, too. >>> >>> Stay out of system directories if you ever can! >>> >>> Marc >>> ================================================================ >>> Marc Scheuner May The Source Be With You! >>> Berne, Switzerland m.scheuner -at- inova.ch >> >> > > >There is another folder called "Common Files" (under Program Files) where various Companies That would be a wise choice - go for it.>store their data (available in .NET, System.Environment.SpecialFolder.CommonProgramFiles). >I am thinking of using this one. Even if a "system" directory (or system file - remember WIN.INI ???) looks intriguiing - it's best to keep your fingers out of there! Marc ================================================================ Marc Scheuner May The Source Be With You! Berne, Switzerland m.scheuner -at- inova.ch Agree. I already implemented "Common Files"-based config settings. Now I
have an extended configuration .NET class that in addition to AppSettings implements MachineSettings and AssemblySettings properties. Looks neat. Thanks for your input, Marc. Vagif Show quoteHide quote "Marc Scheuner [MVP ADSI]" <m.scheuner@inova.SPAMBEGONE.ch> wrote in message news:d8opt0tlrt4gjato2eeq5eu9ev87coor2i@4ax.com... > >There is another folder called "Common Files" (under Program Files) where > >various Companies >>store their data (available in .NET, >>System.Environment.SpecialFolder.CommonProgramFiles). >>I am thinking of using this one. > > That would be a wise choice - go for it. > > Even if a "system" directory (or system file - remember WIN.INI ???) > looks intriguiing - it's best to keep your fingers out of there! > > Marc > ================================================================ > Marc Scheuner May The Source Be With You! > Berne, Switzerland m.scheuner -at- inova.ch Vagif Abilov wrote:
> We have a set of applications and assemblies that belong to one You could use XmlSerializer to serialise a serializable object in one go to > project. Some of the configuration settings are supposed to be shared > between various assemblies on the same machine. After long > discussions we finally decided that the best alternative for us is to > create a custom configuration file <OutProject>.config and place it > in a common directory. Then we can write our own configuration parser > that will return NameValueCollection settings. an XML file, there's no need to write a parser. > There seems to be two good places to install such file: No No No. Don't pollute the system folders.> <Windows>\Microsoft.NET\Framework\<CurrentVersion> and > <Windows>\Microsoft.NET\Framework\<CurrentVersion>\CONFIG. Both of > them contain several configuration files. My first impression was > that the latter one is the best (since it's called CONFIG), however > it contains only system specific configurations files like > machine.config. All application-based config files are located one > level up, inside <Windows>\Microsoft.NET\Framework\<CurrentVersion>. > Do you know what is the best practice? Here's some suggestions.1) Store the file in a folder with the project name under the user's profile local application settings folder. The advantage of this idea is that you guarantee that the user of your app will have access to the file (note that administrators may use NTFS ACLs on a machine to restrict the folders that a user can access). The disadvantage is that every user has their own copy (so deployment is complicated) and you no longer have XCOPY deployment. 2) Organise your applications in a folder structure, eg: Project_Folder | Put the common settings file in Project_Folder. The advantage is that you |----App 1 | |----App 2 know where the file is, you have one copy for all users. The disadvantage is that you are not guaranteed access to this folder, but the administrator will be able to ensure that. Richard Richard,
Thank you for your suggestions. It's a good idea to use XmlSeializer, althouh parsing such simple structures into NameValueCollection is also a very simple thing (but XmlSerializer approach is more elegant indeed). Regarding a place to store the settings, I am now convinced that I should stay away from Framework directories. For the project of our type (the system is configured per machine, not per user, it's a server application), I decided to place config file inside <Program Files>\<Common Files>\<Company Name> folder. The folder <Common Files> contains various common settings and components for different companies, so in case we have stuff to be shared by several of our applications, it feels a good place. Then I wrote a class that extends functionality of ConfigurationSettings class (although it can't inherit from it, because the original class is sealed and only contains static methods). The new class, in addition to AppSettings property, also has AssemblySettings and MachineSettings properties that will return respective parts of common configuration file. Such approach resulted in minimum changes in our code and looks like a natural extension of standard .NET class. Vagif Show quoteHide quote "Richard Grimes [MVP]" <read my sig> wrote in message news:epKjW$P9EHA.1260@TK2MSFTNGP12.phx.gbl... > Vagif Abilov wrote: >> We have a set of applications and assemblies that belong to one >> project. Some of the configuration settings are supposed to be shared >> between various assemblies on the same machine. After long >> discussions we finally decided that the best alternative for us is to >> create a custom configuration file <OutProject>.config and place it >> in a common directory. Then we can write our own configuration parser >> that will return NameValueCollection settings. > > You could use XmlSerializer to serialise a serializable object in one go > to an XML file, there's no need to write a parser. > >> There seems to be two good places to install such file: >> <Windows>\Microsoft.NET\Framework\<CurrentVersion> and >> <Windows>\Microsoft.NET\Framework\<CurrentVersion>\CONFIG. Both of >> them contain several configuration files. My first impression was >> that the latter one is the best (since it's called CONFIG), however >> it contains only system specific configurations files like >> machine.config. All application-based config files are located one >> level up, inside <Windows>\Microsoft.NET\Framework\<CurrentVersion>. > > No No No. Don't pollute the system folders. > >> Do you know what is the best practice? > > Here's some suggestions. > > 1) Store the file in a folder with the project name under the user's > profile local application settings folder. The advantage of this idea is > that you guarantee that the user of your app will have access to the file > (note that administrators may use NTFS ACLs on a machine to restrict the > folders that a user can access). The disadvantage is that every user has > their own copy (so deployment is complicated) and you no longer have XCOPY > deployment. > > 2) Organise your applications in a folder structure, eg: > > Project_Folder > | > |----App 1 > | > |----App 2 > > Put the common settings file in Project_Folder. The advantage is that you > know where the file is, you have one copy for all users. The disadvantage > is that you are not guaranteed access to this folder, but the > administrator will be able to ensure that. > > Richard > -- > www.richardgrimes.com > my email evpun***@zicf.bet is encrypted with ROT13 (www.rot13.org) > >  
Other interesting topics
Exporting registry key to a reg file?
sorting columns of DataSet String conversion from an Object in VB.NET installing .net framework on XP Pro Enum conversion from an Object in VB.NET Error 1937 on VS installation Silent install of .Net Framework 1.1 Determining which Drive is the CD-ROM drive Change of .NET framework website KISS Tutorials |
|||||||||||||||||||||||
