3

I've noticed that if you move that application .exe file in another location the user settings reset.

In my understanding this happens because the location in the app data folder is based on the path of the .exe as well, which is taken into consideration when the hash is being generated.

I know there are different alternatives, either by using the registry or by creating manually a custom config file, but my question is, is it possible to retain the user settings when the application (.exe) is moved to another location with the default functionality Microsoft provides ?

For my tests I use a standalone application (one .exe file only). Simply moving the file to, lets say /Desktop/Test/ from /Desktop/ causes a new folder to be generated under C:\Users\<user>\AppData\Local\<company>\Appname_Url_<hash> with the default user.config in it. The old user.config is still available so if you move the .exe file back to its previous location then the previous settings get loaded again. This becomes troublesome not only because you lose the settings, but if you move the file 10 times in 10 different locations you end up with 10 new folders in the appdata.

coolmine
  • 4,427
  • 2
  • 33
  • 45
  • May be better fit for http://superuser.com. Unless, of course, "that application" is an application you wrote yourself. – Ilya Kurnosov May 26 '13 at 12:05
  • Of course it is, this is a programming related website after all. So the question is related with the software I am writing. Hence the C#/winforms tags :) – coolmine May 26 '13 at 12:07
  • 1
    do you move only the exe file or the all folder ? I think that if you move the all folder it should stay the same – Mzf May 26 '13 at 12:38
  • It is a standalone application (one .exe file only). Simply moving the file to, lets say /Desktop/Test/ from /Desktop/ causes a new folder to be generated under C:\Users\\AppData\Local\\Appname_Url_ with the default user.config in it. The old user.config is still available so if you move the .exe file back to its previous location then the previous settings get loaded again. This becomes troublesome not only because you lose the settings, but if you move the file 10 times in 10 different locations you end up with 10 new folders in the appdata. – coolmine May 26 '13 at 12:45
  • The information in that last comment is useful in explaining your problem and probably should have been included in the question from the start. Quick, use the [edit] link before you get any more downvotes. – Cody Gray - on strike May 26 '13 at 12:55
  • Thanks for the input, I just edited it. For some odd reason I thought this was a common issue so I didn't think it was necessary to expand it more, but this doesn't seem to be the case it seems. – coolmine May 26 '13 at 12:58
  • I can't think of example of a program I installed on my machine that I moved more than *once*. Let alone 10 times, that's just being disorganized. This just is not a real problem, use common sense to pick an install folder name and keep it there. – Hans Passant May 26 '13 at 13:10
  • If that was up to me then that is what I would be doing. But since it is a standalone application there is a high possibility the user will move the .exe file at some point. And sadly, in this case, it takes only once for the file to be moved for the settings to be reset back to the default because of the new file that will be generated in the appdata. So I'm trying to figure out if there is a default functionality in place to avoid that or if I should take the registry route (which I would ideally want to avoid). – coolmine May 26 '13 at 13:32

2 Answers2

3

This is in fact a security feature, related to assembly deployment and clickonce stuff. I think you just need to add a strong name to the main assembly to overcome this issue.

If you don't have a strong name, the name will be something like this and it will change if the application path change (see the Url token):

%appdata%\WindowsFormsApplication1\WindowsFormsApplication1._Url_3pei3cdnq3srqpjiwh1qnf12ncsp5c2w\1.0.0.0\user.config

If you have a strong name it will be something like this and it will not change because your app origin is now identified, whatever its current location is (see the StrongName token):

%appdata%\WindowsFormsApplication1\WindowsFormsApplication1._StrongName_fe0ndyau2vlgeac4gmbg13u3q4jtyrqv\1.0.0.0\user.config
Simon Mourier
  • 132,049
  • 21
  • 248
  • 298
  • This is actually an amazing solution. No one mentioned it in all the posts I read so far and it actually works without any further modifications. Thank you. – coolmine May 29 '13 at 11:40
  • 1
    where do I set the strong name? If I sign the app I need to sign all the other assemblies too and thats not doable in my case. – Tommehh Sep 19 '18 at 08:16
0

From this blog post, regarding the location of the configuration file:

If you need to store the settings in a different location for some reason, the recommended way is to write your own SettingsProvider.

Which tells me that with a little bit of code, you could probably store the file right where you want it, and it won't move.

Steve
  • 6,334
  • 4
  • 39
  • 67
  • This is definitely possible, but how do you reuse the current Visual Studio IDE Settings Editor and the generated associated class then? Even if you write a custom SettingsProvider, you still have to rewrite quite a bunch of code to support that. – Simon Mourier May 29 '13 at 09:12
  • It does indeed work, this was actually my first approach, but the problem begins at the point where you start using different classes in the settings. As an example, http://stackoverflow.com/a/11398536/1630928 suffers from Point/Size classes and I am sure it probably has problems with a few more I haven't tested yet. So I am assuming you will need to write quite a bit of code and do quite a bit of testing to ensure the default functionality is there and even then there are always the things you can't predict :) – coolmine May 29 '13 at 11:47