I have a windows application that uses an assembly that stores some configuration settings in the default application settings.
The settings can be changed in run time and are persisted thus:
Properties.Settings.Default.SelectedCOMPort = options.SelectedCOMPort;
Properties.Settings.Default.Save();
The settings are saved correctly and I confirm this by looking at the user.config file saved in the users application directory E.g.
C:\Documents and Settings\e399536\Local Settings\Application Data\MyCompany\MyTool
However when the tool is closed and then started again all the settings are loaded with their default values.
Checking the user.config file once the application is running confirms that the settings are still as saved.
The settings are loaded thus:
options.SelectedCOMPort = Properties.Settings.Default.SelectedCOMPort;
Why are the default settings being used and not the saved ones?
Have I missed something??
# Tenaciouslmpy
The settings are loaded during the constructor of the assembly, which itself is loaded in the form load event of the main assembly.
# Austin
This is a standalone app that I am debugging in Visual Studio.
If you are recompiling the application between runs, note that it will consider that a new version of the app and will not automatically load per-user settings. You need to call Settings.Default.Upgrade in this situation.
One way to do this only when needed is to add a NeedsUpgrade setting (value True) to the application's default per-user settings. On app startup, check if NeedsUpgrade is true. If so, call Upgrade, set NeedsUpgrade to False, and save the settings. The next time the app version changes, NeedsUpgrade will reset to True and you'll auto-call Upgrade to bring in any existing user settings again.
Make sure you're setting NeedsUpgrade after calling Upgrade, or it will get wiped out when the settings are upgraded.
if (Settings.Default.NeedsUpgrade)
{
Settings.Default.Upgrade();
Settings.Default.NeedsUpgrade = false;
Settings.Default.Save();
}
This sounds like you're debugging the application from Visual Studio when every time you start a new session you start with the default data.
If you're seeing this with an installed release, then I would guess you're not actually using the string values when you think you are.
Related
I have a WPF application that uses the built-in Settings functionality. When I release a new version of the application, I increase the assembly version and execute the following code at application start:
if (Settings.Default.IsSettingsUpgradeRequired) //this defaults to true when a new version of this software has been released
{
Settings.Default.Upgrade(); //upgrade the settings to the newer version
Settings.Default.Reload();
Settings.Default.IsSettingsUpgradeRequired = false;
Settings.Default.LastSettingsUpdate = DateTime.Now.ToShortDateString() + " " + DateTime.Now.ToShortTimeString();
Settings.Default.Save();
}
The problem is that the previous settings are not maintained. Instead, a new folder under \AppData\Local\ is created each time a new version comes up. Thus, the default settings are used instead of those of the previous version. I know that, under normal circumstances, there should be ONE folder that contains many sub-folders with the application's version as name. Instead, I have MANY folders each containing only one folder with the application's version as name.
The folder structure in Local\ looks like this:
myApp.exe_Url_5s2axp5sywfyhblm3201qetpqnmwnvsc
myApp.exe_Url_ft4ih1ze0qsz5abu11t334omxo1431c0
myApp.exe_Url_glsc2d3cjmswry2bxebb53jndfptav1x
myApp.exe_Url_qngn1rqmbfyy42fdgpmc3ystsaknuxnv
myApp.exe_Url_vqn0ogftrchl1fild5fe34hmijvmd2zr
So how do I stop the system to create so many folders and make it only use one folder per application so that I can properly upgrade my settings?
Edit: another thing I noticed today is that if I change the location of the application's folder (lets say move it from desktop to C:\myApp), the application creates a new settings folder when first started. Why does the system not recognize it as the same application?
I finally got it to work. I don't know the cause for the desrcibed behavior, but one of these 2 things fixed it:
Added the default manifest file and changed the "assemblyIdentity" node (the "version" attribute does not seem to have an effect on the Settings)
Activated the signing feature of Visual Studio (Project properties --> Signing)
Project -> Properties -> Application -> Manifest = Embed manifest with default settings
#cleo Thanks for solution. Signing fixed the issue. The folder name no longer changes.
\AppData\Local\MyAppName.exe_StrongName_iyq1qat10dlrezghdzsmthpr49hlodkj
I'm using .NET6 in 2022 and just adding this during app start worked for me:
Settings.Default.Upgrade();
I have created a user setting using visual studio 2010 as below
Client.exe.config
<userSettings>
<Client.Properties.Settings>
<setting name="ParamValue" serializeAs="String">
<value>OFF</value>
</setting>
</Client.Properties.Settings>
</userSettings>
However if i modify the value during runtime from "OFF" to "ON", the application still access the old value. But if i close the app and open again then it reads the updated value.
Is there someway to make the exe read the updated user settings at runtime .
The ApplicationSettingsBase class has a Reload method on it you can use to reload the settings from disk.
Properties.Settings.Default.Reload();
// Properties.Settings.Default.ParamValue will be reloaded from the file on disk.
You didn't specify how you were changing the settings, but it's worth noting that if you update 'User' settings through the 'Save' method of the settings instance, Reload will no longer reset the value if the saved value was different to the default. This is because 'User' settings are written to a settings file in the user profile folder and once they're saved you would have to update that version of the file, not the one in the bin folder for your application.
Specifically, 'User' settings that are saved back to disk through the Save method are written to the following location.
%USERPROFILE%\AppData\Local\<YourAppName>\<MangledName>\<Version>\user.config
If you want to reset your settings back to the default value you've defined in your App.config, use the Reset method.
Properties.Settings.Default.Reset();
// Properties.Settings.Default.ParamValue will be reset to the default.
One approach would be to read the settings into an object on load. Use that object as you want, updating the values if needed. Then on closing of the application write the values of the object back to the config file.
I just published my windows form application(via Build -> Publish Application) and I told the setup to save it in a map. Now the map contains this:
Application Files(folder) -> sync_1_0_0_4(folder) -> sync.application
Setup.exe sync.exe.config.deploy
sync.application sync.exe.deploy
sync.exe.manifest
And some DLLs. Now I want to change a key from the app config, so the most logical thing to do is to open the sync.exe.config.deploy. As I do I see my app config lines just perfectly normal, so I make the desired changes and I run my application. The problem is, nothing has changed in my application. Am I forgetting something? This is my first time publishing a C# application. I've tried this answer: C# - app config doesn't change but it didn't work.
ClickOnce publication does a lot of things. For one, it does cryptographic verification that files haven't changed, so you can't just edit those files. It also copies all deployment files to somewhere on the user's hard drive, and if the app is not reinstalled, and the version doesn't change, then nothing will be copied. And third, if your settings are user scoped, they may have been changed by the user already and won't be reread from the new app config.
Long story short, if you have to change the config, then you have to redeploy, and make sure your settings are application scoped, not user scoped.
I have an app MainApp that references another project MyDLL.dll. Inside the MyDLL project I have made some user settings in a Settings.settings file that may be changed at runtime. So it appears that these settings get saved in the app.config file of MyDLL. But the problem is, the main project is MainApp, and MyDLL.dll.config does not, so far as I can see, get copied to the MainApp output folder. This is reflected in the fact that even though I save the settings in the code of MyDLL, the next time I run MainApp the settings have gone back to the default.
I must be missing something really obvious here. There has to be a way for related assemblies to preserve their settings values. But how?
While you can add an app.config to a library project, it has no effect to do so. Configuration is linked to the application, not the library.
You need to create the settings and configuration in your application itself. You can do something like including the library's app.config if you really wanted to, but that would probably not do what you want, either. It's best to just handle your configuration in the application.
Why is this so? Because what's to say it's valid to have user settings for your library in the first place? A library should not be tied to any particular kind of application. What if you used it in a Windows Service or an ASP.NET application?
According to MSDN, one can add customized settings files to ones project for convenient management of groups of settings.
So I created a custom settings by visual designer, set all properties as a User Scoped to be able to save them.I bind some control properties to this customized settings. And change some values mannually through Properties.CustomSettings.MyValue = x;
But when I do Properties.CustomSettings.Default.Save() - nothing happens. The changes are not persisted between application run (I'm aware about Debug version change) .
I searched a file in the directorites that ConfigurationManager gives me (according to this post) but didn't find any track of this CustomSettings.
So, what is the trick with saving this Customized Settings Files and How to save Customized Settings Files?
Ok, now I've got a right answer. Everything is OK that this custom settings were created under the dll file.
The problem is with this question
Application.UserAppDataPath strange behaviour
If one have AssemblyVersion with automatic Build and Revision Numbers and have AssemblyFileVersion in AseemblyInfo.cs, say, of exe that uses this dll, then Application.UserAppDataPath will throw ArgumentException "Illegal characters in path." Application.UserAppDataPath is used to build path to this config file to save this CustomSettings.
But ApplicationSettingsBase just eats all exceptions that happens inside, so the file is just not saved and nobody could even think about AssemblyFileVersion in AseemblyInfo.cs of exe...
Ohhh my god... 8 hours of fighting with this ... feature...