Where are Settings Stored?

  • Thread starter Thread starter Jonathan Wood
  • Start date Start date
J

Jonathan Wood

I've created a C# desktop application with settings that the application may
modify.

This works fine except for one small issue: When my application modifies
these settings while being run from the IDE, those changes are not visible
when my application runs outside the IDE.

Somehow my project config settings are stored in different placed depending
on how I run my app.

I don't quite understand where this information is being stored. Is there
any way to make all instances of my app use the same settings?

Thanks.

Jonathan
 
Jonathan said:
I've created a C# desktop application with settings that the application
may modify.

This works fine except for one small issue: When my application modifies
these settings while being run from the IDE, those changes are not
visible when my application runs outside the IDE.

Somehow my project config settings are stored in different placed
depending on how I run my app.

I don't quite understand where this information is being stored. Is
there any way to make all instances of my app use the same settings?
Click to expand...

When you start the program within VS, VS actually runs the
"*.vshost.exe" program first, which then "hosts" your actual program.
Thus, the settings wind up in the .config file for the host program, not
your actual program.

I'm not aware of any convenient way to avoid that. There might be an
option in the IDE settings that I've overlooked, but I'm not aware of
anything there. You can always start your program _outside_ the
debugger, and then attach the debugger to it. This will bypass the
hosting behavior for your program.

That said, you may find it's just as convenient to not worry about the
difference. I would not think that most of the time it's important,
because you're either always debugging, or done debugging. For those
times when you really feel you need to switch back and forth, you can
just copy the .config file from one location to the other as needed,
which is probably simpler than going through the "attach to process" UI
in the IDE (especially if you set up a batch file or something for the
purpose).

Pete
 
Peter Duniho said:
When you start the program within VS, VS actually runs the "*.vshost.exe"
program first, which then "hosts" your actual program. Thus, the settings
wind up in the .config file for the host program, not your actual program.

I'm not aware of any convenient way to avoid that. There might be an
option in the IDE settings that I've overlooked, but I'm not aware of
anything there. You can always start your program _outside_ the debugger,
and then attach the debugger to it. This will bypass the hosting behavior
for your program.

That said, you may find it's just as convenient to not worry about the
difference. I would not think that most of the time it's important,
because you're either always debugging, or done debugging. For those
times when you really feel you need to switch back and forth, you can just
copy the .config file from one location to the other as needed, which is
probably simpler than going through the "attach to process" UI in the IDE
(especially if you set up a batch file or something for the purpose).

Pete
Click to expand...
I've seen fairly complex build configurations where the ide switches files
round for you.
Didn't impress me in a positive way though.
Fragile and error prone.
I like things simple.

You can detect whether the debugger is attached and use that to drive a
different bit of processing when you know it's going to be in dev.
That's sometimes useful and almost relevent.
 
Peter said:
When you start the program within VS, VS actually runs the "*.vshost.exe"
program first, which then "hosts" your actual program. Thus, the settings
wind up in the .config file for the host program, not your actual program.

I'm not aware of any convenient way to avoid that. There might be an
option in the IDE settings that I've overlooked, but I'm not aware of
anything there. You can always start your program _outside_ the debugger,
and then attach the debugger to it. This will bypass the hosting behavior
for your program.

That said, you may find it's just as convenient to not worry about the
difference. I would not think that most of the time it's important,
because you're either always debugging, or done debugging. For those
times when you really feel you need to switch back and forth, you can just
copy the .config file from one location to the other as needed, which is
probably simpler than going through the "attach to process" UI in the IDE
(especially if you set up a batch file or something for the purpose).
Click to expand...

Thanks for the additional info. I'm having trouble because a new change has
some lengthy settings data and doesn't prompt you to verify correct data
every time it runs. This is a program I use many times each day and I
sometimes forget which version I'm running. If the data is wrong, it can
cause problems.

I know I can copy the settings, which I'll probably do. I just wanted to
understand this a bit better.

Thanks!

Jon
 
When you start the program within VS, VS actually runs the "*.vshost.exe"
program first, which then "hosts" your actual program. Thus, the settings
wind up in the .config file for the host program, not your actual program.
Click to expand...

If you don't need the functionality that the hosting process provides (and I
never have) you can turn it off in project properties under the Debug tab.
However, I've noticed that even with this off I've seen the behavior
Jonathan describes.
 
Back
Top