0

After EXTENSIVELY researching the ConfigurationManager class, I've decided to just create/read/write to my own file for the single (there will never be more than one option - the task is very specific) user-defined parameter my application will need. In my quest to 'do the right thing' as a new C#/.NET developer (from PHP), I wanted to use ConfigurationManager properly. It can't be as hard as I'm making it out to be - I'm being as honest as I can be when I say that I spent a couple of hours trying to get the settings handled via ConfigurationManager, while it took me about 5 minutes to write the attached code. It would seem to me that this task is something that many apps perform, yet I haven't found a succinct example. Not that I haven't found any examples (Here on MSDN and a few references to similar tasks on SO), but on MSDN, it sure seems like a lot of code for my requirement. At any rate.....

My app requires users to specify a path where files that are generated by the app are stored. My idea for implementation simply has the user selecting an 'Options' setting from the tool strip, selecting a folder to which the files will be stored, and saving that path to a file ([appname.exe.config] if I were using ConfigurationManager). I opted for this old-school approach:

    private void preferencesToolStripMenuItem_Click(object sender, EventArgs e)
    {
        DialogResult result = saveFileLocation.ShowDialog(); 

        string selectedPath = saveFileLocation.SelectedPath;  

        System.IO.StreamWriter file = new System.IO.StreamWriter("config.ini");
        file.WriteLine(selectedPath);
        file.Close();

     }

Notwithstanding the try/catch logic I'll add for exceptions, is there any compelling reason not to handle my needs this way? I'll need to read this file one time when the user processes their request to convert a large array of files.

I understand that the MSDN example is intended to demonstrate the flexibility of the class, but wow, it sure seemed like overkill to me. I don't want to come across as someone who needs copy/paste examples to get things done, but this seems like it would be such a common task that, again, I would have found simpler examples of how to implement my needs via ConfigurationManager.

Thanks in advance for your input.

LovinItAll
  • 133
  • 1
  • 2
  • 8
  • The solution is Here : http://stackoverflow.com/questions/867993/can-i-modify-appname-exe-config-without-having-to-manually-read-write-the-xml Good luck! – Obama Apr 24 '13 at 16:36
  • FYI, that link mentioned above is only applicable if you want to save application-scope settings. For user-scope settings the solution is much easier. Just create the settings you want via the project's Settings tab and then call `Properties.Settings.Default.Save()` after making changes. User-scoped settings are saved in the current user's profile without overwriting the default settings stored alongside your application's executable. – RogerN Apr 24 '13 at 16:59
  • Thank you for the comments. I was actually referencing that page as I was trying to modify my code. When I read, '...However, the setting will not be saved.', I interpreted that to mean that I was barking up the wrong tree. – LovinItAll Apr 24 '13 at 18:54
  • @RogerN - When you say "...via the project's settings tab", are you speaking to a section in the [appname].exe.config, or are you talking about the actual tab in the VS designer ((ApplicationSettings)-Location)? As in, "Put a default location in the 'Location' field within VS, and then change that location on the fly with Properties.Settings.Default.Save? If the latter, that seems perfect...I have to finish a little snippet before I can give that a shot. – LovinItAll Apr 25 '13 at 05:36
  • I was referring to the actual Settings tab in the Visual Studio project properties. Any user-scope settings you add there can be changed on the fly and saved with Properties.Settings.Default.Save. Changes will be serialized to an XML file in the current user's profile; the exact folder name is based on your assembly's meta-data defined in AssemblyInfo.cs. – RogerN Apr 25 '13 at 13:46
  • @RogerN: Thanks, I was playing with that yesterday and ran into an issue that requires yet another question. If I can get this to work the way you've described, it will be quite handy. I appreciate the input. – LovinItAll Apr 26 '13 at 13:44
  • I have no idea why anyone would vote this question down. There is no debating that, for saving a single (and only a single) setting as my app does, the 5-line example works and is simpler than using ConfigurationManager. The question was, "As a new .net developer, is this a bad idea? If so, why?" My app will never use more than one user-defined setting, and I suspect others have/will run into the same issue. I'm unable to find anything that points to the pitfalls of my approach, but I acknowledge that there may be some issue of which I am unaware. I did my research....... – LovinItAll Apr 26 '13 at 13:53
  • The problem with your original approach (writing config.ini) is that you're assuming write permission for the folder in which your program's executable is stored. That's often not the case, particularly in a corporate environment where most users do not have administrative access. The purpose of using the built-in Settings / ConfigurationManager is to delegate the task of saving settings to the user's profile (which you ought to have write access to) to the framework. If someone downvoted your question it's probably because this topic is addressed elsewhere. – RogerN Apr 26 '13 at 15:14
  • @RogerN: I appreciate the response. I have posted another question [HERE](http://stackoverflow.com/questions/16240528/viewing-properties-settings-default-variables) after working with the excellent option you presented above re: the built-in settings. – LovinItAll Apr 26 '13 at 21:28

0 Answers0