[RESOLVED] My.Settings File

I'm looking for a way to specify the location for the User.config file that is used for storing the My.Settings object. It appears that this is not possible.

The problem for me is, I don't want to be responsible for creating several different files on the users computer that really have no use and are difficult to find and clean once an update is released. For most users, this is not a serious problem, as many will probably never update the software, and most will probably only go through a couple of updates. On my system, there are config files for every build of the application, and the same to a lesser extent will be true for my beta testers.

More troublesome is the fact that the settings get reset between versions.

This link http://www.vbforums.com/showpost.php...19&postcount=2 gives an example whereby the MySettings class can be modified to save a duplicate, perstistant settings file which is read and saved after the User.Config file. This solves the problem of persisting settings between versions, but still creates a mess of unusable files on the user's computer.

I can understand that MS wants to make sure that no two applications will use the same location for storing application data, but a simple [UserData]\[CompanyName]\[ApplicationName] for storing application data will probably suffice for 99.9999 percent of the legitimate applications in the world. Bogging a user's system down with erroneous files, no matter how small, is an unnecessary drain on system resources and a potential source of problems for the user. It's bad enough that most programs leave bits and pieces of themselves all over a user's system after deinstallation - this to me seems only to exaggerate this problem.

Is the only way to get around this problem to write a whole new Settings Class? Is there a way to change the location of the UserConfig file to a more friendly (and more predictable) location that I am not finding for myself? It would seem that having at least the OPTION to specify a location for the User.Config file would be OBVIOUS and easy to implement, so why did they leave this out?

Does anyone know how I can persist the settings file between versions and keep from creating a buildup of "orphaned" settings files on the user's computer?

You can setup your own settings class. Granted, it will be difficult, but you could probably do that & use the XML style system that the My.Settings uses. I don't know of a way to set it to persist but someone else might.

I could persist the settings through my own class by specifying a standard location to save the serialized file. I'm hoping someone can point me to something I missed as far as my.settings or somehow to build on the my.settings class to point to a specific location to save the serialized file.

At this stage of development, creating my own class would be a fairly large undertaking - I would have to change all references to my.settings in the code to point to the new class. Unless I can overload my.settings somehow...

Seems silly that we can't specify a location for the My.Settings file.

Hey,

If you are looking to keep the settings in a file that you have more control over, have a look at the serialization link in my signature.

Gary

The answer lies in using a Custom Settings provider.

http://msdn.microsoft.com/en-us/libr...sprovider.aspx

I found this out by accident while researching another question. Some sources state that using a settings provider is simple and straightforward, but finding examples and extended information beyond MSDN seems difficult at best. I have been able to create a custom settings provider that does what I want, but it has created another issue in an unrelated application when implemented with DataSets.

http://www.vbforums.com/showthread.php?t=599834