Updating overwrites the settings with the defaults

[chocolatey-archive]

Updating overwrites the settings with the defaults

[aronovgj]

already mentioned here:
chocolatey-archive/chocolatey#650

also see here:
#11

[ferventcoder]

See chocolatey/choco#110

[TomOne]

Actually this is not a Chocolatey issue. A program should never overwrite the user settings on an update, regardless whether it is handled with a package manager.

[TomOne]

For example, consider CCleaner portable:

The first time an user starts CCleaner.exe, it creates a new ccleaner.ini file for the settings. On an update this file never gets overwritten, because the the ZIP with the CCleaner binaries doesn’t include that file, so the ZIP contents can be safely extracted into the same folder to update CCleaner portable.

chocopkgup should do something similar.

The issue of overwritten settings is a design flaw of chocopkgup and has nothing to do with Chocolatey.

[aronovgj]

does this actually happen anywhere but in the chocopkgup.exe.config?

[TomOne]

does this actually happen anywhere but in the chocopkgup.exe.config?

Any software that uses the same settings file for the default and for the users settings is affected.

[ferventcoder]

We can agree to disagree here. This is going to be handled by Chocolatey.

Let's step away from Chocolatey for a second

Right now for folks to do something like this, they would do it all manually or have some sort of deployment exercise that sets all of the settings for them. There is a config file (as a .net convention) that you make the changes in. People make changes to that manually. So when they upgrade they may have to make changes to it again manually.

Now back to Chocolatey vCurrent

The settings are not actually overwritten. The config file is just in a different location with the old version. The old version they were using still has the settings. It's a small but very important distinction.

Why it's a Chocolatey Issue

As a convention of .NET applications to have a config file that HAS to sit right next to the application, the updating of that should be done by Chocolatey if it is going to handle the auto upgrading of packages because the updating of those files are done now manually or by a deployment.

But let's talk mechanics of WHY it absolutely is a Chocolatey issue to handle

1. .NET applications store the config file next to the application because that is a requirement of .NET. The file has to be next to the executable. In the package directory. So now that we have that out of the way, let's move on.
2. Because I store the config file there, if someone updates stuff there, the config gets updated (that's handled manually in many respects).
3. On upgrade, Chocolatey/choco is going to replace that file without stopping to wait for the app to move it somewhere else/back it up. That's choco updating the package. choco.exe will at least keep the file around with the new versionless folder format (as of 0.9.9-rc8) since there won't be an old directory to go back and compare to.

Why it should not an application issue

EVERY single .NET application would need to do the following:

1. Store your configuration file somewhere else and build a way to update it. Neither of these are trivial.
2. OR use other things for configuration/settings, like the registry (uh, NO :) ).

Building handling your configuration updates is a non-trivial exercise and we should not expect every application that folks want to put on Chocolatey to solve that issue OVER AND OVER. It would be better to have Chocolatey do it once. After all, choco is a framework for making things simpler, not more difficult.

[TomOne]

Ugh, then it’s a design flaw of .NET applications. 😱

Weird that I never had this kind of issue with any of my portableapps. They all work fine with Chocolatey vCurrent, without overwriting the settings. Quite disappointing that Chocolatey has to “fix” this design flaw.

[ferventcoder]

Choco.exe embeds the config file. And it also does lots of magic (and uses a config that is not standard) to work around this. :)

[gep13]

@ferventcoder what happens in the scenario where a new property, that didn't exist in the backed up .config file is added, when an application is upgraded?

[TomOne]

Is .NET really not able to handle such a trivial thing easily? 😕

What if one uses and updates a .NET app without using Chocolatey and it’s workaround for this issue?

IMHO a portable app should be standalone capable and never rely on any workaround mechanism of a package manager.

[gep13]

Within a .Net Application, there is the concept of User Defined Settings, which are stored in the users folder, one for each user, and these don't get overridden on upgrade of the application, however, as Rob pointed out, not everyone uses things like this, and instead use the easiest option, which is to use the default config file.

[TomOne]

Thanks for pointing this out.

Then I was right. This is indeed not a Chocolatey issue, it’s just an app design issue that could be circumvented with external software such as Chocolatey.

I would rather define a proper app design than implementing this creepy workaround. Just my 2 ¢. 😀

[gep13]

I would rather define a proper app design than implementing this creepy workaround. Just my 2 ¢. 😀

And while I can see your point, you have to understand that you are not going to change the world as we know it, overnight. While some applications will do things "properly" there is no guarantee that this will happen. Chocolatey is in a unique position to provide as smooth an update/upgrade process as possible, so that the end user doesn't have to worry about things like this, instead, "it just works".

[dhilgarth]

A very simple solution would be to make use of the configSource attribute in the main config to still use the default. Net configuration system while still being able to move the settings that the user needs to change out to another file

[TomOne]

👍

[ferventcoder]

Here's what's coming for 0.9.9.7 - chocolatey/choco#331

[ferventcoder]

Closed with bc9ee14