Hello Friedrich von Frederick of Fredericksburg,
Thanks for the context. The reason your settings aren’t “sticking” isn’t because of some missing MSI property, it’s because of how .NET application settings actually work, and that behavior is the same in C# as in VB.
In Windows Forms, the .settings file you see in the project is just a design-time definition of settings. At runtime, when you call:
Properties.Settings.Default.Save();
only user-scoped settings are persisted, and they are not saved into the MSI or your installation folder at all. They are written by the .NET runtime into a per-user configuration file in the user’s profile (not in the install directory). This is documented behavior.
So two key points:
- Scope matters Make sure in the Settings designer that the settings you expect to change have Scope = User. If they are Application scope, calling
.Save()doesn’t persist anything because application-scoped settings are read-only at runtime. - MSI installers don’t deploy the user config An MSI will install your application binaries and any default
app.config(which holds defaults), but the actual saved values for user settings are written at runtime into a separate config file under the user’s profile. There is no MSI property to “deploy user settings”.
That explains why you saw this work in VB before: in VB, the settings system automatically saves user settings when the app closes (via My.Settings), whereas in C# you must explicitly call Properties.Settings.Default.Save() after the user changes values.
If you want to verify if the values are being saved at all, you can retrieve the actual file path the runtime uses and inspect it at runtime:
var cfg = System.Configuration.ConfigurationManager
.OpenExeConfiguration(System.Configuration.ConfigurationUserLevel.PerUserRoamingAndLocal);
MessageBox.Show(cfg.FilePath);
That will show you the exact per-user config file being used. If the values aren’t there after you save, then either the scope is wrong or the save call isn’t being reached.
Hope this helps!