I am rewritting my application to conform to ms standards. We used to save all settings to registry for user settings, servername, size and locations.... so we are now saving them into My.Settings app.config the only problem is that each time there is an update clickonce will isnstall the newupdate but now all settings are loist and user has to save everything all over again..

I am trying to follow the book here but it seems i keep getting stuck somewhere. registry has worked fine for years but i understand we must move on, but if stuff like this happens then i just wasted a long time converting all code to conform for it to not work...

Please advise in what steps i need to take, or what i am doing wrong I hope i am doing something wrong then this is the way it was written.

I have read many posts online about this same issue and none seem to have a good reply or answer. If there is no fix let me know i can find other technology to do updates.

Sorry for the delay. (Working a lot these days.)

Ok, so here's the deal. Application settings can not be overwritten by the user, so when you change them in the project, it does deploy the new version over the old.

If you want to store user-specific settings that can be changed by the user, you need to use user-scoped settings instead. Then after the values are modified (My.Settings.MyFieldName = value), save the settings (My.Settings.Save)

It will save them under the \data folder for the ClickOnce deployment.

Then if you change the values in the project and redeploy, it will still use the ones in the ClickOnce data folder, which you can continue to programmatically modify and save.

What we did (because we wanted more control) was roll our own configuration manager, keeping a list of key/value pairs. If you want to store this kind of information in a different format in a different file, you can create a folder under LocalApplicationData with your company name, and store it there. This is the recommended placement for this kind of data on Windows Vista and above, where security is stronger. To get the base path for this folder:

Dim userFilePath as string = Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData)

Dim myAppCache = Path.Combine(userFilePath, "mycompany")
If (!Folder.Exists(myAppCache))
Directory.Create(myAppCache)
End If

Here's another article that discusses the same issues: http://blogs.msdn.com/rprabhu/articles/433979.aspx

RobinDotNet

If you want to users to be able to acess settings and things stored in isolated storage after you push out a new release you need to:
1. KeepthesameAseembly Version. You can change the File Version but not the Assembly Version.
2. Strong Name sign the executable.

You should also be aware that Settings information is stored under Local Settings and will not persist to a roaming profile.

You can persist items in Isolated Storage if you use:
isFile = IsolatedStorageFile.GetStore(IsolatedStorageScope.Roaming Or IsolatedStorageScope.User Or IsolatedStorageScope.Assembly Or IsolatedStorageScope.Domain, Nothing, Nothing)
That will put IsolatedStorage under Applicatoin Data which is persisted to a roaming profile.

saberman -- I completely disagree with your answer here

Sorry for the delay. (Working a lot these days.)

Ok, so here's the deal. Application settings can not be overwritten by the user, so when you change them in the project, it does deploy the new version over the old.

If you want to store user-specific settings that can be changed by the user, you need to use user-scoped settings instead. Then after the values are modified (My.Settings.MyFieldName = value), save the settings (My.Settings.Save)

It will save them under the \data folder for the ClickOnce deployment.

Then if you change the values in the project and redeploy, it will still use the ones in the ClickOnce data folder, which you can continue to programmatically modify and save.

What we did (because we wanted more control) was roll our own configuration manager, keeping a list of key/value pairs. If you want to store this kind of information in a different format in a different file, you can create a folder under LocalApplicationData with your company name, and store it there. This is the recommended placement for this kind of data on Windows Vista and above, where security is stronger. To get the base path for this folder:

Dim userFilePath as string = Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData)

Dim myAppCache = Path.Combine(userFilePath, "mycompany")
If (!Folder.Exists(myAppCache))
Directory.Create(myAppCache)
End If

Here's another article that discusses the same issues: http://blogs.msdn.com/rprabhu/articles/433979.aspx

RobinDotNet

I don't agree -- it doesn't have anything to do with the assembly version or the file version. You have to be able to change the version in order to deploy updates.

Second, MSFT recommends that extraneous data be stored in LocalApplicationData rather than Isolated Storage.