locked
Where should a config file be stored? RRS feed

  • Question

  • I have written a program that creates an .xml config file if one does not exist. The config is stored in the same folder as the .exe
    I am using ClickOnce as my deployment solution.

    (Program written in C#)

    The problem is that when a user upgrades the program the config.xml file is removed. This causes the user to have to suffer through the setup wizard after every update.

    How can I prevent the config.xml file from being removed?
    Is there a special directory I should be storing the file in?

    Any suggestions or advice would be greatly welcomed. ;)
    Wednesday, August 3, 2005 2:14 AM

Answers

  • Originally I had wanted to create my own config.xml for learning purposes and to have complete control.

    Is there any other way besides using the settings designer-generated settings API in this situation?

    Say if I were to store the config.xml in the Application Data folder, would ClickOnce remove that during upgrade?
    Wednesday, August 3, 2005 2:36 AM
  • What JBrown said is the simplest method, but there is also IsolatedStorage.  Personally, I'd use Isolated Storage because, although it's more of a hassle, it allows you have lower FileIO permission requirements.
    Friday, August 5, 2005 2:42 PM

All replies

  • Is there any reason that you can't use the settings designer/client configuration API for your configuration settings instead of having your own custom configuration file? The settings designer-generated settings supports upgrading in click-once.

    Best regards,
    Johan Stenberg

    Wednesday, August 3, 2005 2:26 AM
  • Originally I had wanted to create my own config.xml for learning purposes and to have complete control.

    Is there any other way besides using the settings designer-generated settings API in this situation?

    Say if I were to store the config.xml in the Application Data folder, would ClickOnce remove that during upgrade?
    Wednesday, August 3, 2005 2:36 AM
  • Thanks for that last reply Johan.
    I will definately check those pages out, the answer seems to lie in the second page you linked to.

    For My Information: Are there any benefits to using the built-in config API besides it being managed?
    Wednesday, August 3, 2005 3:02 AM
  • Some of the things that the client config API supports are:

    * It supports roaming and local settings for per-user (user scoped) settings
    * It automatically upgrades your settings in a click-once scenario
    * It supports databinding for per-user (user scoped) settings
    * It has the ability to use other custom setting providers that store the settings somewhere else (i.e. web service, database)
    * It is possible (but not as easy as I'd like) to encrypt sections of the configuration files containing the settings using the Config Management APIs.

    If I were to write an application, I would definately take a serious look at this API.

    Best regards,
    Johan Stenberg
    Wednesday, August 3, 2005 3:20 AM
  • Ok, I've been doing my homework and finally decided on a path to take.

    I am sticking with my Configuration.dll (manages an xml config file) since I already have it built and it works exactly the way I want it to.

    So I adjusted the doc.Load function to store the config file in the ClickOnce data directory.

    doc.Load(Application.UserAppDataPath + "\\" + filename); // Open or Create config file in the Data Dir

    The problem is that the Configuration.dll is unable to write to or create the file in the data directory. Since I am using ClickOnce I assume this is a security permissions problem. I have allowed my program Full Trust but the .dll still does not create the config file.

    I would like to have the config files be user-scoped and not application-scoped, so I am hesisitant about using the isolated storage store which as I understand it does not require Full Trust permissions.

    Wednesday, August 3, 2005 10:52 PM
  • What JBrown said is the simplest method, but there is also IsolatedStorage.  Personally, I'd use Isolated Storage because, although it's more of a hassle, it allows you have lower FileIO permission requirements.
    Friday, August 5, 2005 2:42 PM