Using Configuration file in Windows Apps

[Raphael Iloh]

Hi all, I just installed VS.NET 2003 and seem to be having a couple of
teething problems.

I have a Windows application developed in VS.NET 2002. During debugging I
normally placed the configuration file in the debug folder since that's
where the executable is found. This worked just fine. However, when I tried
compiling and debugging the same application using VS.NET 2003, the
configuration file gets deleted from the debug folder each time I compile,
thus denying the application of data stored in the config file. Is there a
way to work around this?

 

[Herfried K. Wagner [MVP]]

Hello,

I have a Windows application developed in VS.NET 2002.
During debugging I normally placed the configuration file in
the debug folder since that's where the executable is found.
This worked just fine. However, when I tried compiling and
debugging the same application using VS.NET 2003, the
configuration file gets deleted from the debug folder each
time I compile, thus denying the application of data stored
in the config file. Is there a way to work around this?

Add the config file to your project's main folder (not the "debug" folder).
Then add the file to your project. When compiling the file will be copied
to the debug folder automatically.

HTH,
Herfried K. Wagner

 

[=?ISO-8859-1?Q?Christian_Fr=F6schlin?=]

Add the config file to your project's main folder (not the "debug" folder).
Then add the file to your project. When compiling the file will be copied
to the debug folder automatically.

This will only work when the configuration file is constant. If the
application modifies the configuration file (e.g. user changes options),
then these changes will be written to the temporary file.

I am not using VS 2003, but I would not be happy if it deletes
files from the executing directory which it knows nothing about.

 

[Raphael Iloh]

....I tried that option too but the application wouldn't 'see' the config
file. I even switched the build action for the config file from 'none' to
'content' yet with no success. 'Copying to debug folder' wasn't done
automatically, is there something that needs be set for this to happen?
--
Regards,
Raphael Iloh (www.ilohraphael.net)
MCP, MCAD (C#)
This Posting is provided "AS IS", with no warranties and confers no rights.

 

[Herfried K. Wagner [MVP]]

Hello,

This will only work when the configuration file is constant. If the
application modifies the configuration file (e.g. user changes options),
then these changes will be written to the temporary file.

I am not using VS 2003, but I would not be happy if it deletes
files from the executing directory which it knows nothing about.

I always thought that the config file should not be changed by the
application (it's not intended for saving user preferences).

Regards,
Herfried K. Wagner

 

[Stefan Simek]

It's really simple...

Just select Add New Item... from the project menu, and then select the
"Application configuration file" from the list (the last item). This creates
the 'app.config' file, which will be then copied into the bin directory
under a proper name (e.g. MyApp.exe.config).

Hope this helps...
Stefan

 

[=?ISO-8859-1?Q?Christian_Fr=F6schlin?=]

I always thought that the config file should not be changed by the
application (it's not intended for saving user preferences).

Sorry, I did not notice you were talking about a special config file.
I was referring to the general case that an application might wish to
store its settings in a file which resides in the same directory as
the executable (which our product does, in fact). So it would be
highly undesirable if VS 2003 decided to trash the Debug directory
on every compilation.

I assume the above behavior then only occurs for that special file.

 

[Raphael Iloh]

....thanks a million Stefan it worked as you'd explained (without changing
the suggested file name); I actually created the config file manually but it
didn't work. Then I created the config file using the 'Add New Item' Dialog,
but I changed the suggested name of the file to 'myapp.exe.config' and it
still didn't work. Apparaently, there's more to it than just creating a file
and adding it to the project, MS should advise. Once again thanks...

 

[=?ISO-8859-1?Q?Christian_Fr=F6schlin?=]

data in the same directory as the EXE, because normal
(non-administrator) user accounts under NT/2k/XP don't have write
access to Program Files and its subdirectories.

I cannot confirm this. I never had problems writing there in either
of the systems mentioned above, at least not as "Power User". Even
as a normal user it seemed to work, except that we experienced problems
which we think are related to the writing of binaries (*.oca) by the
development environment when using our ocx.

Is there a particular reason why your config settings have to be
stored in the program directory, and can't be stored in something
like isolated storage or
Environment.SpecialFolder.[Common]ApplicationData?

Actually, we offer ActiveX controls which need to persist changes
applied to them at run-time in a manner which works both in .NET
and older environments. Since they can be used in multiple
applications on one system, we store the data next to the EXE.

They are used for very specialised industrial applications,
so it is not really a problem to request Power User privileges
for the process.

 

[Joe White]

You're right, Power Users also have write access to Program Files. But
granting Power User access is a bad idea, precisely *because* they have
write access to Program Files -- it's a bigger security risk (e-mail
viruses, malicious employees, etc.)

(Sorry, I've been reading books and articles on security lately. Does
it show? <grin>)

Anyway, it's little to no extra effort to put your data under
Application Data, and then your users don't need any extra permissions.
MS's security features are there for a reason; it's better to work
with them (when you can) than work around them.

data in the same directory as the EXE, because normal
(non-administrator) user accounts under NT/2k/XP don't have write
access to Program Files and its subdirectories.

I cannot confirm this. I never had problems writing there in either
of the systems mentioned above, at least not as "Power User". Even
as a normal user it seemed to work, except that we experienced problems
which we think are related to the writing of binaries (*.oca) by the
development environment when using our ocx.

Is there a particular reason why your config settings have to be
stored in the program directory, and can't be stored in something
like isolated storage or
Environment.SpecialFolder.[Common]ApplicationData?

Actually, we offer ActiveX controls which need to persist changes
applied to them at run-time in a manner which works both in .NET
and older environments. Since they can be used in multiple
applications on one system, we store the data next to the EXE.

They are used for very specialised industrial applications,
so it is not really a problem to request Power User privileges
for the process.

 

[=?ISO-8859-1?Q?Christian_Fr=F6schlin?=]

Anyway, it's little to no extra effort to put your data under
Application Data, and then your users don't need any extra permissions.
MS's security features are there for a reason; it's better to work with
them (when you can) than work around them.

I agree, but you might have missed the second part of my post.