I have a Full trust, online only, click-once application that relies on settings in the App.config --> appSettings collection.
Once published, the first time the application is executed, the settings are read and everything works fine. If I close the application and run it again, the items that are in appSettings are no longer there and appSettings.Count is equal to 0.
I have set the app.config as "Content" and to "Copy Always".
Any Idea what could be causing the items in appSettings to disappear? or a way to get around this?
Also, please note that the settings are only being read, and being used to determine how the application is run. We're not trying to manipulate the settings.
I guess you are using the settings wrong.
First of all, you need to mind the difference between application and user settings. Application settings are constant and can not be changed from your code (for example default values, connection strings, etc.). User settings are for settings that change when the application runs, usually because there is some sort of Settings dialog in your application.
Secondly, you need to access them properly. People tend to (and I don't know why) use things like ConfigurationManager or other stuff to access settings. It is far easier and less error-prone to use Properties.Settings.Default.SettingName for both application and user settings.
Changing a user setting would read like this:
Properties.Settings.Default.SettingName = settingValue;
Properties.Settings.Default.Save();
The call to Save is important, as otherwise the change will not be persisted.
Thirdly: No need to change the way app.config is included in your project. By default it will be renamed to applicationname.exe.config and will always be included in your output unless you say otherwise. The same goes for the ClickOnce installation: It will be included by default. You may actually break things if you play with this or the ClickOnce deployment settings for app.config! Revert them to default and leave them alone.
Now one case where the settings will be lost and reverted to defaults is when you update your application. In this case you will have to migrate your settings from the previously installed version, otherwise the user settings will be overridden with the default values from the installation. What you do to migrate the settings is:
Define a user setting named SettingsUpgradeRequired (name doesn't really matter - should be self-explaining, however) with a default value of true in the settings designer. Then, when your application starts, you do this:
if (Properties.Settings.Default.SettingsUpgradeRequired)
{
Properties.Settings.Default.Upgrade();
Properties.Settings.Default.SettingsUpgradeRequired = false;
Properties.Settings.Default.Save();
}
This makes sure a migration of the settings only occurs when required. SettingsUpgradeRequired will only be true upon the first installation (in which case Upgrade does nothing) and after an update of your application, because - as I said - by default the configuration from the ClickOnce installation will override the previous configuration until you perform the upgrade.
Related
I'm using Settings.Settings to store settings at run-time. It was very helpful for my earlier application to store data. But in my current project its not saving the settings data. My application have some tab and each tab contains some TextBox. Im using textBox Text to store string values.
Properties.Settings.Default.Setting1 = textBox2.Text;
Properties.Settings.Default.Save();
It is a working method for my all previous application.But I can't understand why its not working in my current project.
Since your question does not include many details, I've tried to answer as much as possible:
Try to perform a Properties.Settings.Default.Upgrade() and then saved settings get loaded.
You have to call the Upgrade method of ApplicationSettingsBase derived class (that is normally called Settings and is created for you by Visual Studio)
Properties.Settings.Default.Upgrade();
When/where to call the Upgrade method? There is a simple trick you can apply: define a user setting called UpgradeRequired (example) as bool (the easiest way is through IDE). Make sure its default value is true.
Insert this code snipped at the start of the application:
if (Properties.Settings.Default.UpgradeRequired)
{
Properties.Settings.Default.Upgrade();
Properties.Settings.Default.UpgradeRequired = false;
Properties.Settings.Default.Save();
}
So the Upgrade method will be called only after the version changes and only one time (since you disable further upgrades by setting UpgradeRequired = false until a version change - when the property regains default value of true).
Check the scope of your settings [USER/APPLICATION]
Try this out, and if it doesn't work check the below conditions.
Also, a more detailed question next time would be much appreciated.
Permission (NTFS permission)
Or Active directory permission
Or capacity of windows drive is full.
Or there exist two or more user folders and you checked another.
For example: There are two or three folders, user.domain, user.workgroupname, user.
Despite all this, I suggest you to learn about System.Reflection and develop your personalized method to save settings, the option provided by the Visual Studio isn't very dependable.
Hope this was helpful.
I've got a Winforms app that has quite a few settings (.settings file). These are saved (as far as I can tell) in C:\Users\[User's username]\AppData\Local\[My program name]\[Build or something]\1.0.0.0\user.config but whenever I make a new build and a user runs that version, it makes a new [Build or something] folder and starts over with a "fresh set" of settings. What is the best practice for rolling over the settings from a previous version?
(Some settings I want to be "brand new" every time a new version is run and some settings I want to be copied from the last version)
I am using method described in this post (it says Clickonce but it is also applicable to other types of apps): https://blogs.msdn.microsoft.com/rprabhu/2005/06/29/client-settings-faq/
Q: Okay, but how do I know when to call Upgrade?
A: Good question. In Clickonce, when you install a new version of your application, ApplicationSettingsBase will detect it and automatically upgrade settings for you at the point settings are loaded. In non-Clickonce cases, there is no automatic upgrade – you have to call Upgrade yourself. Here is one idea for determining when to call Upgrade:
Have a boolean setting called CallUpgrade and give it a default value of true. When your app starts up, you can do something like:
if (Properties.Settings.Default.CallUpgrade) {
Properties.Settings.Default.Upgrade();
Properties.Settings.Default.CallUpgrade = false;
}
This will ensure that Upgrade() is called only the first time the application runs after a new version is deployed.
I'm developing an application that saves various user settings (e.g. window locations, options, preferences). This is done using the syntax
Properties.Settings.Default.setting_name = "xxx";
Properties.Settings.Default.Save();
and
var x = Properties.Settings.Default.setting_name;
Here is an example of the underlying settings file path:-
C:\Users\user_name\AppData\Local\company_name\exe_name.vsh_Url_kxrjspzszls01bmlnkpeuf5cutfdioia\1.0.0.0
The problem is that each time I build and release a new version of the software, users are losing their settings. This is presumably down to the fact that the application exe version number is being included in the file path, so each time a new version is installed it starts over with a new, empty settings folder? Fortunately we're still in the dev phase so it's only a couple of internal users at present.
What's going on, and is there a way around it?
I'm also concerned because we have an existing product out in the field, and are due to release a new version shortly. I'm panicking that all these users will lose their settings and preferences when they upgrade.
So based on other SO questions and articles found on the web, I've written this short method that I now call during application startup:
private static void CheckForUserSettingsUpgrade()
{
if (!Properties.Settings.Default.UserSettingsUpgradeRequired)
{
return;
}
Properties.Settings.Default.Upgrade();
Properties.Settings.Default.UserSettingsUpgradeRequired = false;
Properties.Settings.Default.Save();
}
For this to work there must be a user-scope setting called UserSettingsUpgradeRequired with a default value of True.
After an upgrade (resulting in a new settings file being created) this setting's value will of course be true. In this scenario the above code will import all settings from the previous settings file (if any), set this upgrade flag setting to false, then save the changes. After the next upgrade, the flag's value will revert to true, and the process will repeat itself.
I have a windows application. I am writing all user specific settings into user.config.
Now in a new scenario, whatever changes one user does it should reflect to all the users.
For that purpose I thought of writing the settings into app.config through
Properties.Settings.Default.p1 = value;
Properties.Settings.Default.Save();
And every user read the updated default value after
Reset();
But what ever I do…it still writes to user.config not to app.config
From my experience, the Settings class cannot be used to modify default setting values for all users. In this situation, I modify the app.config directly using the classes in the System.Xml namespace. It is not ideal, but I have not found any other way to do it.
There are a couple things to keep in mind when modifying your app.config file:
If your program is installed in the Program Files folder, you may need to run your application as an administrator in order to save changes to the file. It will depend on how your security is configured.
If you change the namespace of your Settings class, it will change the structure of your app.config file, so you would need to update your code to account for the new XML structure.
See this MSDN article for more information about application and user scoped settings:
http://msdn.microsoft.com/en-us/library/8eyb2ct1%28v=vs.110%29.aspx
I've been trying to modify my application to deploy and update using ClickOnce. I've managed to get the program working but I'm having trouble with the program configuration. My program uses a custom XML configuration file located in the application directory. This raises 2 major problems.
1.) The configuration file is very hard to get to. Without knowledge of how ClickOnce works the user will not be able to locate it.
2.) Currently if I change the configuration file ClickOnce automatically "updates" the configuration file to the original version, destroying my configuration.
Ideally I would like it to move the configuration file to another location and create a start menu shortcut to it next to my application. But if I change the program to do this can I still deploy the application using ClickOnce?
Thanks in advance,
Fr33dan
Why don't you put a copy of the configuration in the users app data folder (this can be done on first run) - then have a button in your application which opens it (either externally or in your application)?
You can always store your configuration data in the Application Settings. This won't get overwritten on every ClickOnce change or update (unless you change the Type of the setting). You can then create a simple form to update it. That's the technique many .NET developers use for screensavers.
There are a number of things you can do here to mitigate this as a problem.
Firstly, using what's already there - the configuration data has two parts (excuse me as I'm working from memory) app config and user config. The app config is basically defined when the app is pulled down however the user config is just that - you set up the defaults and then, once set by the application on behalf of the user, it won't be overwritten when the app is updated.
It should be straightforward enough to provide a configuration editor - something as simple as a two column grid would be sufficient with a read only label column and an editable value column (although you're going to be somewhat challenged on validation).
Alternatively, if you're happier with a more traditional configuration, then you need precisely 1 user value and that would be the location for the config file... if you don't know if (or can't find the file) prompt to create, dump your default config to the specified location from a resource within you app and then you've got your config file and away you go.
One project I worked on, we made the app download a configuration file from the server it was deployed from (this was done on each startup to cope with if app was added to the Start Menu and cached). The ClickOnce API gives you the server address.
On another project we just pass a few config values as query strings to the ClickOnce app, these were generated by the Asp.net page that had the link to the app.
This allowed customers to change the config for their site without having to resign etc.
(This does not help with per-user config)