You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The default form of Application Settings (File) will only automatically upgrade when using a pure ClickOnce installation. In order to have a smooth user experience, we need to manually call the Upgrade method to carry over the old version of Settings.
Todo
Verify this works (Settings remain blank, no errors) when running without an existing older copy
Test with older running installation of WinNUT
Modify issues for ClickOnce to remove this code once deploying full ClickOnce installation.
When a new version of an application is installed, ClickOnce will copy all the existing data files from the previous version's Data Directory into the new version's Data Directory—whether they were included in the original deployment or created by the application.
It seems that this copy operation is not happening. Most likely because we are still using the MSI for deployment rather than true ClickOnce.
If you need finer-grained migration of data, you can use the ClickOnce Deployment API to perform custom migration from the old Data Directory to the new Data Directory. You will have to test for an available download by using IsFirstRun, download the update using Update or UpdateAsync, and do any custom data migration work in your own after the update is finished.
In the meantime, figure out how to do this custom data migration work.
When your user upgrades to a later version of your application, application settings compares most recent (highest-numbered) version's settings against the settings supplied with the updated version and merges the settings into a new set of settings files.
...
If you have created your own application settings wrapper class and wish to customize the update logic, you can override the Upgrade method.
Even though we are using the standard application settings class, we may need to either call or modify the Upgrade method.
According to the Upgrade method of the LocalFileSettingsProvider...
This way this method is called depends on the type of application that is being upgraded:
Each version of a ClickOnce application is stored in its own isolated installation directory. After a new version of a ClickOnce application is installed, and when the new version is first run, internal logic will automatically call Upgrade to migrate all common application settings to the new version. For more information, see ClickOnce and Application Settings.
Standard Windows Forms and console applications must manually call Upgrade, because there is not a general, automatic way to determine when such an application is first run. The two common ways to do this are either from the installation program or using from the application itself, using a persisted property, often named something like IsFirstRun.
As long as we deploy the Setup Project MSI type, we'll need to manually run the Upgrade method with Default settings to try and detect a previous version, unless the Setup project is modified to run this procedure manually.
Alternate solution - trigger settings upgrade from MSI upgrade
It seems that detecting an upgrade installation from the MSI its self is difficult and requires modifying the MSI post-build. May be best to stick to the previous suggestion from Microsoft - use a persisted property in the Settings.
The text was updated successfully, but these errors were encountered:
@masterwishx Looks like this may be fixed now, go ahead and update WinNUT and your settings should carry over now. Let me know in here if the issues persist.
@masterwishx Looks like this may be fixed now, go ahead and update WinNUT and your settings should carry over now. Let me know in here if the issues persist.
The default form of Application Settings (File) will only automatically upgrade when using a pure ClickOnce installation. In order to have a smooth user experience, we need to manually call the
Upgrade
method to carry over the old version of Settings.Todo
Notes
Data directory and application versions
It seems that this copy operation is not happening. Most likely because we are still using the MSI for deployment rather than true ClickOnce.
In the meantime, figure out how to do this custom data migration work.
ClickOnce and application settings
Even though we are using the standard application settings class, we may need to either call or modify the Upgrade method.
According to the Upgrade method of the LocalFileSettingsProvider...
Each version of a ClickOnce application is stored in its own isolated installation directory. After a new version of a ClickOnce application is installed, and when the new version is first run, internal logic will automatically call Upgrade to migrate all common application settings to the new version. For more information, see ClickOnce and Application Settings.
Standard Windows Forms and console applications must manually call Upgrade, because there is not a general, automatic way to determine when such an application is first run. The two common ways to do this are either from the installation program or using from the application itself, using a persisted property, often named something like IsFirstRun.
As long as we deploy the Setup Project MSI type, we'll need to manually run the Upgrade method with Default settings to try and detect a previous version, unless the Setup project is modified to run this procedure manually.
Alternate solution - trigger settings upgrade from MSI upgrade
It seems that detecting an upgrade installation from the MSI its self is difficult and requires modifying the MSI post-build. May be best to stick to the previous suggestion from Microsoft - use a persisted property in the Settings.
The text was updated successfully, but these errors were encountered: