• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 291
  • Last Modified:

Where did my files go?

My application has an XML file that holds the settings. Whenever I add some features, re-compile, and re-publish using ClickOnce, and then someone clicks "OK" because there is an update available, the settings file, settings.xml, is not retained.

It looks like that every version gets installed under appdata as a new version, which is why settings.xml is no longer available.

Question: how do I make the settings file persistent so that even though an upgrade comes down the pipe, and the client gets the new version of the program, they don't have to go through and re-enter all their settings?
0
DrDamnit
Asked:
DrDamnit
  • 3
  • 3
  • 2
1 Solution
 
Jacques Bourgeois (James Burger)PresidentCommented:
You need to Upgrade the settings in the newer version.
My.Settings.Upgrade()

Open in new window

There seem to be a little bug with that however. It should not be a big problem, but might be annoying for some.

This works everywhere except when you install through ClickOnce on the same computer that holds the server from which the application is deployed.

This happens on my station, that is at the same time my usual workstation, my development station and the on on which I run my server. What I do is that on that station, I do not use the application through a ClickOnce install, but I use it directly from the compilation directory. This has an extra advantage: I get the debugger when there is a bug while I am using the application for real work.
0
 
CodeCruiserCommented:
Can you not use the app.exe.config file with settings having User scope. I think these settings do not get reset during updates.
0
 
Jacques Bourgeois (James Burger)PresidentCommented:
@CodeCruiser.

Contrary to standard Windows Application, with ClickOnce, the User scoped settings get overwritten when you install a new version of the application, because the AppData directory for a ClickOnce install is different for all versions.

This is why an Update has to be called. It will copy the already existing settings from the old configuration file to the new one.
0
Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

 
CodeCruiserCommented:
Yeah looks that way. Here is some info

http://msdn.microsoft.com/en-us/library/ms228995.aspx
0
 
DrDamnitAuthor Commented:
I am not using app.exe.config. I am using a custom file that is created at runtime called settings.xml.

My.Settings.Upgrade() doesn't appear to know about the file.

But... your post gave me the idea to use: My.Computer.FileSystem.SpecialDirectories.CurrentUserApplicationData & "myapp\settings.xml"

That works like a charm, and no upgrade needed.
0
 
DrDamnitAuthor Commented:
This post gave me the idea to use: My.Computer.FileSystem.SpecialDirectories.CurrentUserApplicationData
0
 
Jacques Bourgeois (James Burger)PresidentCommented:
No wonder that My.Settings.Upgrade does nothing. Your settings and "our" settings are not the same.

Your use of the term "settings" misled us. A standard configuration file in .NET is prepared by using the Settings tab of the project properties, and My.Settings is the class used to write and retrieve information from the configuration file. So we thought that this is what you were talking about.

You are right, My.Computer.FileSystem.SpecialDirectories.CurrentUserApplicationData & "myapp\settings.xml"
would probably work (we do not have the big picture, thus the "would").

But I would add 2 remarks.

First one. My is a namespace that makes things easy for amateur programmers, for whom it was conceived. But it also hides a lot of possibilities. While you have 30 or so methods to work with files, directories and drives through My.Computer.FileSystem, you have more than that only for files, only for directories and only for drives through the System.IO namespace. This gives you a lot more to "play" with. If you program for fun, My.Computer.FileSystem is probably sufficient. But if programming is part of your job, working with the classes in System.IO will open more possibilities.

Second one. There is already an easy to use feature to work with "settings" in the framework: the configuration file. This thing has been designed by people who know the framework and it intricacies a lot more than any of the "experts" here, because they designed .NET. Why work hard to try to implement something on your own, when the one that is already there is doing the job for almost everybody. There are probably thing you did not think about that the programmers at Microsoft knew and cared for.

If it is there, and if it is well designed and work, and if you do not need something very special, using what is already there is both the easiest and best way to do things.
0
 
DrDamnitAuthor Commented:
I code utilities to make my job easier. So, I cannot say that I am full-time 40 hours a week coding by an means of the imagination. But, I have been coding for 20+ years in multiple languages. Most of the time, however, it is not .NET. :-)

I didn't know about the settings class, and will certainly use that from now on rather than coding my own settings files from scratch.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

  • 3
  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now