Changing settings for a project at design-time may erase settings set during run-time

[BrianCook]

This says nothing about the very inconvenient behavior which is that if you add a new setting, any saved values of your previous settings are all lost! You have to re-enter ALL the settings anytime you add a new one. Not friendly behavior, and not documented, nor documented what the workaround is.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 16d9fd0d-871f-557d-972b-398bbe91f68a
• Version Independent ID: 4ca53b82-cb2b-1ccd-8fa8-e37557ce77ee
• Content: How To: Create a New Setting at Design Time - Windows Forms .NET Framework
• Content Source: dotnet-desktop-guide/framework/winforms/advanced/how-to-create-a-new-setting-at-design-time.md
• Product: dotnet-framework
• Technology: dotnet-winforms
• GitHub Login: @adegeo
• Microsoft Alias: adegeo

[mairaw]

@Tanya-Solyanik are you aware of any issues with that?

@BrianCook can you provide more info on which version of VS you're using, language, etc.? I can't reproduce this with VS 2017. I can add new values without losing the old values.

[Tanya-Solyanik]

No, I'm not aware of this issue. I had experimented like this: 1 Added 2 settings to a settings file, saved the settings, restarted the application 2. read back the saved value 3. added a new setting value to the same setting file, rebuilt, restarted the app, the previously saved values are read back, and the new value is initialized to the value defined in the designer, as expected. 4. Added a new Settings1.Setting file, it did not affect the saved value.

We definitely need more info here. @BrianCook - are you running your application as the same user before and after adding new settings values? Had the name your binary changed?

[BrianCook]

It is easy to duplicate in VS 2017, happens every time for me.

1. Add a string setting named "Setting1" to the Windows Forms program using the settings designer. Leave default value as blank.
2. Run your program, save a new string value to Setting1.
3. Restart program, can read Setting1 with the new value.
4. Now add another string Setting2 to the settings, also with default value blank.
5. Run your program, now if you read Setting1 it comes out blank with the default value and you lost the settings you saved in step 2.

If I look in my User/MyName/AppData/Local folder under my app name, it creates new subfolder with a different name every time I edit the settings in the designer. Each new subfolder has the default settings and loses all saved settings from before.

This is extremely annoying when those saved settings are long paths to places in your file system and you have to re-pick them every time you add a setting. I basically cut and paste between the settings files to save time.

Thanks,

Brian

On Wed, May 2, 2018 at 12:50 PM, Tanya Solyanik [email protected] wrote:

No, I'm not aware of this issue. I had experimented like this: 1 Added 2 settings to a settings file, saved the settings, restarted the application 2. read back the saved value 3. added a new setting value to the same setting file, rebuilt, restarted the app, the previously saved values are read back, and the new value is initialized to the value defined in the designer, as expected. 4. Added a new Settings1.Setting file, it did not affect the saved value.

We definitely need more info here. @BrianCook https://github.com/BrianCook - are you running your application as the same user before and after adding new settings values? Had the name your binary changed?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dotnet/docs/issues/5111#issuecomment-386063544, or mute the thread https://github.com/notifications/unsubscribe-auth/AET_Wz7WyFEHekEIK35Ya4rtX9zUhrCaks5tufHKgaJpZM4TucjW .

[Tanya-Solyanik]

I re-run your scenario and settings under user profile were not erased on steps 4-5. Are you incrementing assembly version of every re-build? How does the path to the stored settings look like? What version of the framework are you targeting?

C:\Users\me\AppData\Local\WindowsFormsApp25\WindowsFormsApp25.exe_Url_yl2wkiizt1bkjvqiwmxjsaiggyrhktvh\1.0.0.0

[BillWagner]

@BrianCook Are you still having this issue? Did you try the suggestions from @Tanya-Solyanik ? If the issue is fixed, we'll close this. If not, we'd like to get to the root cause.

[BrianCook]

Yes, I still have the issue (although it does not bother me except when I add settings)

I can try to put together a specific re-creation and send you a project that exhibits the behavior, along with screenshots of my local settings folder.

If I do this, what is the best way to send it to you? Do I need to create a github project and share it with you?

Thanks,

Brian

On Wed, May 23, 2018 at 9:10 AM, Bill Wagner [email protected] wrote:

@BrianCook https://github.com/BrianCook Are you still having this issue? Did you try the suggestions from @Tanya-Solyanik https://github.com/Tanya-Solyanik ? If the issue is fixed, we'll close this. If not, we'd like to get to the root cause.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dotnet/docs/issues/5111#issuecomment-391361439, or mute the thread https://github.com/notifications/unsubscribe-auth/AET_WxOWniLG5pBcsuuCtdN0vbKcOqu3ks5t1W3fgaJpZM4TucjW .

[BillWagner]

Thanks @BrianCook

Either a GitHub gist, or a GitHub project would be perfect. Thank you

[BillWagner]

@BrianCook Any updates?

[BrianCook]

I have attached a Word doc showing the problem in detail. Please let me know if you need any other information.

Thanks,

Brian

On Mon, Jun 4, 2018 at 2:57 PM, Bill Wagner [email protected] wrote:

@BrianCook https://github.com/BrianCook Any updates?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dotnet/docs/issues/5111#issuecomment-394479024, or mute the thread https://github.com/notifications/unsubscribe-auth/AET_W3AT3UZm0zlk-wS9eKLMZUG4J3fWks5t5ZElgaJpZM4TucjW .

[BillWagner]

@BrianCook Attachments sent via mail aren't attached on the GitHub website. Can you visit this page and upload the doc?

Thanks.

[BrianCook]

See attached doc VS Settings Upgrade Issues.docx

[dotnet-bot]

This issue has been closed as part of the issue backlog grooming process outlined in dotnet/docs#22351.

That automated process may have closed some issues that should be addressed. If you think this is one of them, reopen it with a comment explaining why. Tag the @dotnet/docs team for visibility.

[baddoggames]

I still think this is a real issue that should be addressed. Saving settings is a fundamental framework feature and the behavior is still badly designed and not documented. Tagging @dotnet/docs per the email about the automatic purge dotnet/docs#22351.

[BrianCook]

I left a comment on dotnet/docs#5111 but it does not let me reopen the issue.

I still think this is a real issue that should be addressed. Saving settings is a fundamental framework feature and the behavior is still badly designed and not documented, as I carefully documented in the attached Word doc. Why would anyone want or expect a settings feature to require you to re-enter ALL your saved settings any time anything changes in your build?

Tagging @dotnet/docs per the email about the automatic purge dotnet/docs#22351.

On Mon, Jan 25, 2021 at 8:34 AM dotnet bot [email protected] wrote:

Closed dotnet/docs#5111 https://github.com/dotnet/docs/issues/5111.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dotnet/docs/issues/5111#event-4245904594, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABCP6WZATOFMASXNQZMU35LS3V6RHANCNFSM4E5ZZDLA .

[adegeo]

After doing some research I think we can update these how-to articles with a note about User settings. The overview for this doc area should probably mention something too. I think that the overview is out of date because it talks about the config file being saved as user.config where user is the user's name.

I believe the following statements are true:

1. The app uses a unique folder for user settings in the appdata directory. The folder is generated based on (1) the app's assembly information (2) the path to the executable. And, this folder (and the subsequent config file) is only generated when the app needs to store changed user settings.

2. If any information about the assembly changes, or the assembly or has a different path (more than one copy of the executable, or simply moving the executable to a different folder) you'll get a new user settings folder path and your previously saved settings will not persist.

I'm still trying to understand the nuances

[adegeo]

I was looking at this yesterday (and will continue to today to actually make some doc updates) and I was unable to replicate lost settings. Using Visual Studio 2022 and targeting .NET Framework 4.8 I did the following:

1. Create a new app with two textboxes and with load and save buttons
2. Edit the settings file to add two settings both with defaults blank
3. Ran the app and set textbox1 to a value and saved. Closed the app.
4. Ran the app again and loaded settings. I see my user setting. Closed the app.
5. I added 3 more settings to the settings, 2 user settings, 1 with a custom default value. The other setting was app scope with a default set.
6. Added more textboxes to the app to load the new user settings and app settings.
7. Ran the app and loaded the settings, my previously set settings loaded fine as well as the new user settings with a default and app scope setting with default.
8. Repeated the process of adding more settings to the file, everything still worked as expected.

I dug into the .NET Framework source to figure out what it does to generate the user scope settings file. ClientConfigPaths Line 191 builds the folder name based off of three values:

1. The company name of the assembly
2. A hashed value of a combined string consisting of both (Assembly friendly name or product name) and (strong name or file path of the assembly)
3. The assembly ProductVersion

Anything that changes this, such as switching from debug to release (which puts the assembly in the bin\Release|Debug\ folder) would change your config file location. Another possible change to this value would be if you had any build events that alter the version file, such as a X.X.X.#### that increases every time you compile, that would result in you having a new config every time you compile.