CODEWITHSUNDEEP
.netfilepathisolatedstorageapplication-settings
Hasan Baidoun
Hasan Baidoun

Reputation: 1155

.Net User Scope Application Settings file path issue

I am building a Windows Forms App using .Net Framework 3.5 and later. I am facing an issue using the Application Settings in the User scope.

When I first read about the User scope application settings I understood that my application will relate the settings to the user. I also learned from MSDN that the settings will persist in the user.config file under the path : %LOCALAPPDATA%\CompanyName\ProductName\ProductVersion which is the same exact value returned by the field Application.LocalUserAppDataPath Reference: http://msdn.microsoft.com/en-us/library/8eyb2ct1.aspx

The issue here, is that all of what's written in the MSDN about the file path is totally wrong. And experiments shows clearly that the file path in fact is : %LOCALAPPDATA%\companyname\appdomainname_eid_hash\verison

First of all, I really care about knowing what could be a rational explanation for why such an important piece of info is wrong in MSDN?

Secondly, the issue here is that I am not using an Deployment method in .Net (e.g. Windows Installer or ClickOnce) and I am not intending to use them, and I don't want to use them. Here I am only building a release and them copy the release exe file to the host computer. Because I am not using an installer, every time I change the location of the assembly (i.e. exe file) the .Net Framework recognize the assembly as a different application and creates a new folder for it with different hash and a new user.config file. This is of course an issue for me, because it means that those I am considering are not the "User Settings" rather they are the "User and Assembly settings", it's just logically not right for me. I don't find a reason why the user can relocate the assembly to anywhere and still have access to the same settings file (as the MSDN falsely states!!)

More over, the same exact issue is facing me using the IsolatedStorage. Also in IsolatedStorage, all the data I store when the assembly is in some location gets totally unaccessible as I relocate the exe file for the same exact reason as in the issue with the Application Settings.

How can I resolve this, or at least may I know where that naming convention with hashing originate from in .Net and what's the reasoning that Microsoft may have done when decided to consider the exe relocation accordingly??

Upvotes: 4

Views: 955

Answers (1)

dhope
dhope

Reputation: 46

I do not have an answer for why the documentation on MSDN is incorrect, though you should ensure you are looking at the correct version of the documentation for .net 3.5 found at https://msdn.microsoft.com/en-us/library/8eyb2ct1(v=vs.90).aspx

Also, according to the documentation:

Settings File Locations

The location of the app.exe.config and user.config files will differ based on how the application is installed. (my emphasis added)

The application settings processes are tightly coupled to the deployment, which you are bypassing. Even with click-once, some deployment strategies require programmatically getting the previous versions settings depending on your application (https://msdn.microsoft.com/en-us/library/system.configuration.applicationsettingsbase.getpreviousversion(v=vs.90).aspx)

If it is a requirement that you need to manually copy the .exe every time there is an update, perhaps rolling your own user settings object and using serialization would be a better alternative? Then you could store the user scoped settings in a common location, like the common application folder, and deserialize user settings based on the user when the application starts.

Upvotes: 1

Related Questions