I have so many bloody different nested folders with different names that were all automatically created by the settings engine that I can no longer tell where the active settings file resides on my machine. Is there a way to determine the path to the active settings file programmatically so I can output it to a debug console?
It isn't often that I can post the exact same answer within 2 minutes. Copy-and-paste:
I'm going to be a bit blunt about this. The .NET framework design is overall rather excellent. Easy to learn, few surprises, no fat. But not everything is great. System.Configuration has a very high suck factor. Between an absurdly complicated object model and an implementation that was paralyzed by security concerns, it inevitably becomes a PITA when you try to extend it beyond the point-and-click settings designer.
Just don't go there. Using XML serialization to load/save your own configuration class(es) is a wholeheckofalot easier than battling that borked design.
Related
I'm refactoring a WPF application and dealing with cleaning up storage of settings. I've re-written most to use the application's settings (Properties.Settings.Default) and this technically is working right now it seems to generate rather ugly paths in the %appdata% folder such as:
C:\Users\me\AppData\Local\Company_Name_With_Underscores\program.exe_Url_xs3vufrvyvfeg4xv01dvlt54k5g2xzfr\3.0.1.0\
These also then result in a new version number folder for each version that don't get cleaned up ever unless apparently I manually do so via file io functions.
Other programs don't seem to follow this format, including Microsoft programs, so I'm under the impression this seems like one of those 'technically the best way but not practical so nobody uses' solutions. Is this the case or am I missing something to make this more practical?
I ask mainly because I can foresee issues if we ever have to direct a customer to one of these folders to check or send us a file from there.
I'm using .NET 4.0 right now.
All, I have a large C# application that I am writing a plugin for. I want to provide settings for this plugin and came to the conclusion that writing my own setting manager ect. and creating XML settings which would be put in the relevant special folders is the best way to go. However, I can't remember why (after coming back to project) I came to that conclusion over using the Properties.Settings.MySetting route. Can someone offer any advice in terms of what method is more preferable in my case?
Is writing my own overkill here, or is there a clear and obvious benefit?
I aplogise if I have asked this on the wrong Stack site.
Thanks very much for your time.
It's a good question and I'd like to let you know that you came to that decision because your DLL plugin cannot normally work with its own app.config file (where the settings are stored).
This happens because the ConfigurationManager looks for app.config files attached to the executing process, which is main exe file.
You got several options over here, and the best one is to point the configuration manager which file to use as a config file which is greatly described at this page.
I'm currently working on a Winforms app created by someone else. I've noticed that all the configurations are stored in the registy. This includes connection strings and so on.
Is this good or bad practice? If bad, then what is the better alternative?
A better option for you and the user is to use configuration files stored in the per-user application data directories. Look at the documentation for the System.Configuration namespace. Version 2.0 of the framework added a lot of functionality beyond the per-application config files.
I think a better option would be to store them in an app.config. This gives better visability and frankly is easier to change.
If you want to hide your app settings, most users aren't savvy enough to go hunting through the registry for keys relevant to an application. Also, as other answers have pointed out, back in the days before XML configuration file standards, the registry was the recommended place.
The recommended option is an XML config file nowadays; it won't add data to a file that's loaded at startup, meaning you're not contributing quite as much to the problem of a computer with a lot on it getting an inflated registry. It's more easily changeable (provided your user has admin access, and in any case, your program will need special permission to access the file to make programmatic changes).
If you kind of want to keep the data away from the casual user, a SQLite database is a relatively lightweight way to store small amounts of data, like user settings, in a manner that isn't easily changeable without access to SQLite. Just remember that if you can get in, so can others, no matter how hard that may be.
It's mostly an old practice from pre .NET days (VB6 comes to mind), when there were no standard configuration files and Microsoft recommended storing configuration in the registry.
These days, the registry is a good place to store information that is used by several applications, but if this is not the case, you should prefer the application configuration file.
I think this is what the asker of this question is getting at, but its hard to tell and there's no accepted answer...
I have a C# app built using visual studios application settings. A really useful feature would be the ability to export the settings in one file. Similarly it would be useful to be able to import configuration files exported by another instance.
I guess this would ordinarily be a matter of copying and pasting the file they're stored in, but my users won't be savvy enough for that sort of thing, so I'd like to do it through menus and dialogues.
To complicate matters, I had to add my own settings class in addition to Properties.Settings (the visual studio default) and I'd like the generated file to be a merge of the two sets of options. (To confuse matters further, I'm not sure where the custom settings file is being saved, but that's a separate question methinks...)
So to recap:
Where is my custom settings class likely to save it's XML?
How would I go about merging the two files?
On import, how could I split them?
I'm going to be a bit blunt about this. The .NET framework design is overall rather excellent. Easy to learn, few surprises, no fat. But not everything is great. System.Configuration has a very high suck factor. Between an absurdly complicated object model and an implementation that was paralyzed by security concerns, it inevitably becomes a PITA when you try to extend it beyond the point-and-click settings designer.
Just don't go there. Using XML serialization to load/save your own configuration class(es) is a wholeheckofalot easier than battling that borked design.
I'm reviewing a .NET project, and I came across some pretty heavy usage of .ini files for configuration. I would much prefer to use app.config files instead, but before I jump in and make an issue out of this with the devs, I wonder if there are any valid reasons to favor .ini files over app.config?
Well, on average, .INI files are probably more compact and in a way more readable to humans. XML is a bit of a pain to read, and its quite verbose.
However, app.config of course is the standard .NET configuration mechanism that is supported in .NET and has lots of hooks and ways to do things. If you go with .INI files, you're basically "rolling your own all the way". Classic case of "reinventing the wheel".
Then again: is there any chance this is a project that started its life before .NET ? Or a port of an existing pre-.NET Windows app where .INI files were the way to go?
There's nothing inherently wrong with .INI files I think - they're just not really suported in .NET anymore, and you're on your own for extending them, handling them etc. And it certainly is a "stumper" if you ever need to bring outside help on board - hardly any .NET developer will have been exposed to .INI files while the .NET config system is fairly widely known and understood.
Ini files are quite okay in my book. The problem is GetPrivateProfileString() and cousins. Appcompat has turned that into one ugly mutt of an API function. Retrieving a single ini value takes about 50 milliseconds, that's a mountain of time on a modern PC.
But the biggest problem is that you can't control the encoding of the INI file. Windows will always use the system code page to interpret strings. Which is only okay as long as your program doesn't travel far from your desk. If it does, it has a serious risk of producing gibberish when you don't restrict the character set used in your INI file to ASCII.
XML doesn't have this problem, it is well supported by the .NET framework. Whether by using settings or managing your config yourself.
Personally I never user .ini /xml config files to anything more than loading all the values into a singleton or something and then use them runtime like this...
That being said i firmly believe that you should look at the kind of data and the use of data. If the data is in the context of the application in terms of settings and comfigurations then i believe that the app.config file is the right place to hold these settings.
If on the other hand the data is concerned about loading projects, images or other resources concerned with the content of the application then i believe the .ini (does anyone use .ini files anymore? I am thinking a .xml file for storing these information). In short: Segment the content of the data being stored according to the domain and the context.
INI files are preferable for multi-platform applications (e.g., Linux & Windows), where the customer may occasionally edit the configuration parameters directly, and where you want a more user-friendly/-recognizable file name without the extra effort.