.Net file path.

Question

I am building a Windows Forms application using .Net Framework 3.5 and later. I ran into a problem using application settings in the "User" area.

When I first read about the settings of the application "Scope", I realized that my application would associate the settings with the user. I also learned from MSDN that the settings will be saved in the user.config file along the path: % LOCALAPPDATA% \ CompanyName \ ProductName \ ProductVersion which is the same exact value returned by the Application.LocalUserAppDataPath field Link: http://msdn.microsoft.com /en-us/library/8eyb2ct1.aspx

The problem here is that everything that is written in MSDN about the file path is completely wrong. And experiments clearly show that the file path is actually: % LOCALAPPDATA% \ companyname \ appdomainname_eid_hash \ verison

First of all, I’m really interested to know what could be a rational explanation of why such an important piece of information is incorrect on MSDN?

Secondly, the problem is that I do not use the Deployment method in .Net (for example, the Windows installer or ClickOnce), and I am not going to use them, and I do not want to use them. Here I just create a release and they copy the exe release file to the host computer. Since I do not use the installer, every time I change the assembly location (that is, an exe file), the .NET Framework recognizes the assembly as another application and creates a new folder for it with a different hash and a new user.config file. This, of course, is a problem for me, because that means that the ones I'm considering are not “user preferences”, but rather are “user and build preferences”, it just doesn't logically work for me. I don’t find the reason why the user can move the assembly to any point and still have access to the same settings file (since MSDN is falsely declaring !!)

Moreover, the same question is facing me using IsolStorage. Also in IsolatedStorage, all the data that I store when the assembly is in some place becomes completely inaccessible, since I am moving the exe file for the same exact reason as in the problem with the application settings.

How can I solve this, or at least I can find out where this hash naming convention comes from .Net and what arguments Microsoft could make when it decided to revise the exe translation accordingly?

Answer 1

I have no answer why the MSDN documentation is incorrect, although you should make sure that you are looking for the correct version of the documentation for .net 3.5 found at https://msdn.microsoft.com/en-us/library/8eyb2ct1(v=vs. 90) .aspx

In addition, according to the documentation:

Location of settings files

The location of app.exe.config and the user.config files will differ depending on how the application is installed. (added by me)

Application parameter processes are closely related to the deployment that you bypass. Even with a single click, some deployment strategies require programmatically retrieving the settings of previous versions depending on your application ( https://msdn.microsoft.com/en-us/library/system.configuration.applicationsettingsbase.getpreviousversion(v=vs.90) .aspx )

If you require you to manually copy .exe each time there is an update, maybe switching your own custom settings object and using serialization would be a better alternative? Then you can save the user coverage settings in a general place, for example, in the application’s shared folder, and deserialize user-based user settings when the application starts.