none
Settings file loses values upon ClickOnce Update

    Question

  • I have read the numerous questions here on this topic and even posted one of my own(at StackOverflow) trying to get to the bottom of this([My Previous Question]). Unfortunately, none of them answer my question.

    My `.Settings` file get's reset whenever I deploy an update through ClickOnce. I thought ClickOnce was supposed to handle this sort of thing for me(See Here) but since it seems no, so I implemented the `.Upgrade()` with a Settings Flag like so:

     

    if (Settings.Default.MustUpgradeSettings)
                {
                    Settings.Default.Upgrade();
                    Settings.Default.MustUpgradeSettings = false;
                    Settings.Default.Save();
                }
    

     

    Which I check `OnLoad()` but it still resets the Settings. Am I missing something? This is seriously driving me nuts!


    Sa souvraya niende misain ye
    Friday, September 16, 2011 3:46 PM

All replies

  • I have read the numerous questions here on this topic and even posted one of my own(at StackOverflow) trying to get to the bottom of this([My Previous Question]).  Unfortunately, none of them answer my question. 

    My `.Settings` file get's reset whenever I deploy an update through ClickOnce.  I thought ClickOnce was supposed to handle this sort of thing for me(See Here) but since it seems no, so I implemented the `.Upgrade()` with a Settings Flag like so:

     

    if (Settings.Default.MustUpgradeSettings)
                {
                    Settings.Default.Upgrade();
                    Settings.Default.MustUpgradeSettings = false;
                    Settings.Default.Save();
                }
    

     

    Which I check `OnLoad()` but it still resets the Settings.  Am I missing something?  This is seriously driving me nuts!


    Sa souvraya niende misain ye
    Friday, September 16, 2011 3:21 PM
  • Unfortunately, you've posted your Click Once question in the wrong forum. This forum is for .NET Framework setup and installation questions.

    On the bright side, there is a forum dedicated to Click Once issues, where you're much more likely to get good suggestions:

    http://social.msdn.microsoft.com/Forums/en-US/winformssetup/threads

    Friday, September 16, 2011 3:43 PM
  • Hi,

    Here are two resolved thread on how to keep the settings without upgrating by using the ClickOnce:

    http://social.msdn.microsoft.com/Forums/en/winformssetup/thread/49240d9a-448b-437c-a434-a7e17108e3ff

    http://social.msdn.microsoft.com/Forums/en-US/winformssetup/thread/21ec76e1-4c5c-4ae9-856f-72268c2f60f8/

    If you have any questions, please feel free to tell us.

    Best Regards


    Neddy Ren [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Monday, September 19, 2011 9:19 AM
  • Thank you for the response, it helps somewhat.  However I am still confused, The links seem to point out that my user.settings file should be automatically upgraded when I deploy using ClickOnce but that is precisely what I am saying isn't happening.  The one post points out it was a bug in .Net 2.0 but that was 6 years ago.  Can any further help be provided, why doesn't it work the way it sounds like it is supposed to by default.  That is unless I am misunderstanding....
    Sa souvraya niende misain ye
    Tuesday, September 20, 2011 4:30 PM
  • Hi,

    Let's see the specifications on MSDN Librbary:

    Just as each version of a ClickOnce application is isolated from all other versions, the application settings for a ClickOnce application are isolated from the settings for other versions as well.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.

    The following table describes how application settings decides which settings to copy. 

    Type of Change

    Upgrade Action

    Setting added to app.exe.config

    The new setting is merged into the current version's app.exe.config

    Setting removed from app.exe.config

    The old setting is removed from the current version's app.exe.config

    Setting's default changed; local setting still set to original default in user.config

    The setting is merged into the current version's user.config with the new default as the value

    Setting's default changed; setting set to non-default in user.config

    The setting is merged into the current version's user.config with the non-default value retained

    If you have created your own application settings wrapper class and wish to customize the update logic, you can override the Upgrade method.

    You can see it form the following page:

    http://msdn.microsoft.com/en-us/library/ms228995.aspx 

    Best Regards


    Neddy Ren [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Wednesday, September 21, 2011 6:29 AM
  • Thank you Neddy Ren for your continued efforts.

    However, that chart is exactly what I am referring to, specifically the 4th "Type of Change", as that is NOT happening. My user's settings file, which I understand to be a wrapper for user.config, is being changed after deployment by either the code or a GUI interface.  The settings changes persist for that user through restart's but when I deploy an update it is being reset. 

    So, am I missing something subtle, what else can I look at as, to me, it seems that mine is not working then way MSDN is saying it should.


    Sa souvraya niende misain ye
    Wednesday, September 21, 2011 1:28 PM
  • Thank you Neddy Ren for your continued efforts.

    However, that chart is exactly what I am referring to, specifically the 4th "Type of Change", as that is NOT happening. My user's settings file, which I understand to be a wrapper for user.config, is being changed after deployment by either the code or a GUI interface.  The settings changes persist for that user through restart's but when I deploy an update it is being reset. 

    So, am I missing something subtle, what else can I look at as, to me, it seems that mine is not working then way MSDN is saying it should.


    Sa souvraya niende misain ye


    Maybe you have set the default values to the  settings'.  The 4th "type of Change" work only for the "non-default". Have you set the default value to the settings?

    On the other hand, I have searched another examples for you on how to persist the settings:

    Windows Forms - Creating and Persisting Custom User Settings in C# - Part 2:
    http://www.codeproject.com/KB/cs/WinAppUserSettings2.aspx

    Windows Forms - Creating and Persisting Custom User Settings in C#:
    http://www.codeproject.com/KB/cs/WinAppUserSettings.aspx

    Best Regards


    Neddy Ren [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    • Proposed as answer by TylerGG Friday, September 30, 2011 7:20 AM
    Thursday, September 22, 2011 7:25 AM
  • Maybe that's my problem, how do I set the Default Values?  I had aassumed that whatever I set them to in the Designer in VS 2010 is what the Default was.

    I will take a look at your links, it is, however, still frustrating that it is not working the way the documentation says it should and no one can provide me with a reason or even something to look for....


    Sa souvraya niende misain ye
    Thursday, September 22, 2011 2:32 PM
  •  

    Hi RefractedPaladin,

    How's everything going?

    I think Neddy has pointed you the two links that are more likely to suit your needs, and you may have a try on that. We are not quite sure why your application is not working the same way as the doucmentation says, as we don't have the details.

    If you need further help to find out the root cause of this issue for your application, you may need to pursue a more in-depth level of support, as it falls into the paid support category. Please visit the below link to see the various paid support options that are available to better meet your needs.

    http://support.microsoft.com/default.aspx?id=fh;en-us;offerprophone

     

    Thank you!

    Best Regards,

    Wendy

    Friday, September 30, 2011 7:15 AM