User settings and config files

[LJB]

This is not exactly a C# question by my app is in C# and I'm new to .Net. In
my development and testing cycle I frequently must delete folders similar to
"C:\Documents and Settings\user\Local Settings\Application
Data\company\program.vshost.exe*".
I'm afraid this may become a problem after deployment too. How do I deal
with these user settings files? One version of my app is deployed with only
the default settings. The same version may be deployed a second or third
time on the same PC but with program.exe.config files containing settings
that override the defaults. Frequently old user settings seem to override
the new config files. Only after deleting the user settings files will my
app function correctly. I see the user settings files all reference an exe
version number. Is that sufficient to prevent these conflicts after
deployment?

Thanks,
LJB

 

[Peter Duniho]

This is not exactly a C# question

Closer than some we get.

by my app is in C# and I'm new to .Net. In
my development and testing cycle I frequently must delete folders similar to
"C:\Documents and Settings\user\Local Settings\Application
Data\company\program.vshost.exe*".

When you run your program in the debugger, the .exe that is the main
..exe for the process is that special "vshost" .exe. You can see it if
you look in the output directory for your project.

Since the config file directory name takes the .exe name, run in the
debugger the config file directory name winds up with the "vshost" filename.

On a non-development, real-world deployment computer you should never
see a directory like that.

I'm afraid this may become a problem after deployment too. How do I deal
with these user settings files? One version of my app is deployed with only
the default settings. The same version may be deployed a second or third
time on the same PC but with program.exe.config files containing settings
that override the defaults.

What do you mean "deployed a second or third time"? Is that in separate
users? If so, then there should never be a conflict between user-scoped
settings. If not in separate users, then why would the application be
deployed multiple times, are you dealing with application- or user-scope
settings, and how do you implement the installation of settings?

Frequently old user settings seem to override
the new config files. Only after deleting the user settings files will my
app function correctly. I see the user settings files all reference an exe
version number. Is that sufficient to prevent these conflicts after
deployment?

I believe that you can use the version number to control how the
settings are interpreted, yes. That's so two versions of the
application can co-exist on the same computer without interfering with
each other.

But you seem to be concerned about the opposite: an older version of the
application is interfering with a newer one. That shouldn't normally
happen.

If you can be more specific about how exactly you're dealing with the
user settings, and what your specific design goals are, that would be
helpful.

Pete

 

[Van den Bogaert Joachim]

How do I deal

with these user settings files? One version of my app is deployed with only
the default settings. The same version may be deployed a second or third
time on the same PC but with program.exe.config files containing settings
that override the defaults. Frequently old user settings seem to override
the new config files. Only after deleting the user settings files will my
app function correctly.

Have you tried the following? In your setup project you can add a
special folder and copy the config files when your app is being
deployed. I assume the old files get overwritten.

http://msdn.microsoft.com/en-us/library/ms242499(VS.80).aspx

Regards,
Joachim

 

[LJB]

Closer than some we get.


When you run your program in the debugger, the .exe that is the main .exe
for the process is that special "vshost" .exe. You can see it if you look
in the output directory for your project.

Since the config file directory name takes the .exe name, run in the
debugger the config file directory name winds up with the "vshost"
filename.

On a non-development, real-world deployment computer you should never see
a directory like that.


What do you mean "deployed a second or third time"? Is that in separate
users? If so, then there should never be a conflict between user-scoped
settings. If not in separate users, then why would the application be
deployed multiple times, are you dealing with application- or user-scope
settings, and how do you implement the installation of settings?

All are for one user. The application is installed in several folders each
with a unique config file and xml files. The output has a different format
and destination

I believe that you can use the version number to control how the settings
are interpreted, yes. That's so two versions of the application can
co-exist on the same computer without interfering with each other.

I've been trying to remember to change the version number for each build
today and that seems to solve the problems in testing. So the final
deployment should be OK too.

But you seem to be concerned about the opposite: an older version of the
application is interfering with a newer one. That shouldn't normally
happen.

If you can be more specific about how exactly you're dealing with the user
settings, and what your specific design goals are, that would be helpful.

Pete

Thanks for the info.