riceman0
asked on
VB.NET Application settings
Hey, I just made the switch to VB.NET from VB6.0, and I see that there are properties on every control called Application Settings. Seems like they are a way to bind properties to a configuration file, to make certain settings persistent, right?
Even back in VB6.0 I was old-school about making my apps persistent, I would use INI files instead of the registry... I'll be darned if I'm going to bury important data in a place where nobody can ever edit it. Rolled my own little class to save/load all my required INI settings, it served me very well for a long time.
So before I invest a lot of time in learning, implementing, and evaluating Application Settings, does anybody have an opinion, are they worth a darn? Are the saved somewhere that makes sense, and editable? Do they have a real advantage over INI files?
Scoring high, hoping to split it among a few good perspectives. Thanks!
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
By the way, I'll spread the points between all useful, persuasive, and/or informed answers, whether "yes" or "no".
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I don't "want" to hear yes, and the links are helpful but not actually what I'm asking for. I don't want (or have time to) try it out unless someone says something convincing (from personal experience) about how it has improved things for them over traditional config files. Trying to get the aggregate opinion. I'm not looking for a reason, I'm just interested in (a) doing things the best way, and (b) NOT wasting time learning things that aren't the best way. I also recognize there is often a difference between the latest way, and the best way.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Honestly, no, I don't give a whit what microsoft titles "best practice" in their documentation, except where it coincides with what actually makes sense (which is more often than not). Going back to my comparison, at one time Microsoft considered putting your settings in the registry the "best practice", and that was just goofy.
I was pleased that it only took me about 30 minutes to convert my interface INIFile class and skeleton INI module to .NET (although I'll probably find better commands for things, and it'll need to be refactored).
I've played around with the My.Settings. Pretty slick designer (project settings tab), although two drawbacks:
a) I don't like having design buried in the project, rather than represented by code. We try to write very up-front, reviewable code here, and that interface is harder to describe to a reviewer, and harder for him to verify. Does the designer put the settings code somewhere that we could inspect?
b) I'm trying to figure out whether XML is indeed as readable and editable as the INI format is. I'm leaning towards no (yeah, I know XML is sexier).
c) still figuring out how it handles defaults; with INI commands you supply a default, so basically you could delete your INI file to restore factory config settings, very nice.
ASKER
By the way thanks for the tidbit about IIS, I do write web apps from time to time. Those are the things I'm looking for: secular, technical things that I wouldn't discover/realize until I get far down the road with the technology that make me love it or hate it.
ASKER
Hmm, don't see my .config file. Your comment raises a question though, when you deploy an app EXE to a new computer, and there is no BIN subfolder, where does the app.config file go, in the local directory?
Seems complex, though. Main thrust of my question: does it have the edge over easy-as-pie INI files? Unless I get a definitive "yes" from someone, not even going to try it, sit this one out like I sat out the inferior registry settings.