Using a different filename for App.config

  • Thread starter Thread starter shawnn
  • Start date Start date
S

shawnn

Hello,

By default, when you create an App.config file it gets named as
MyApp.exe.config after build. I don't like this name and would rather
have the file named MyApp.config, the .exe.config thing might confuse
my users. Is there any way to do this, or am I stuck with
MyApp.exe.config??

Thanks.
 
Hi,

Hello,

By default, when you create an App.config file it gets named as
MyApp.exe.config after build. I don't like this name and would rather
have the file named MyApp.config, the .exe.config thing might confuse
my users. Is there any way to do this, or am I stuck with
MyApp.exe.config??

AFAIK there is no way to change it IF you want to use the framework supplied
classes, of course there is nothing to prevent you from creating your own
file (and format ) and just read the configuration from this file, it's just
that you will have to c reate all the functionality.
 
Aside from rolling your own config, you're stuck, I believe.

You can specify an external file for your appSettings, though, if that's
what your users are going to need to mess with, though. I don't remember the
parameter name exactly, but if you're using VS 2005, you can go to the
appSettings secion, and get intellisense for the settings on the appSettings
section. It will look something like this:
<appSettings file="myApp.config" />
All key/value pairs would move into myApp.config. I also don't believe that
it has to end with .config.

It's been my experience that if you're programatically modifying your
appSettings, you'll have problems.
 
ummm... confusing to your users? they shouldn't be looking at it
anyhow (by default, most of them won't even see the extension in
Windows Explorer). But more importantly, how about: confusing to
future maintainers of your code or confusing to the administrator of
your app?

There is no reason to do this.
 
Ok I guess I had some misconceptions about the App.config file. What am
I "supposed" to store in this file if not user options and things like
that?

Suppose I just want to remember user settings. What is the "best" way
of doing this with C# .NET? Just come up with my own format and
manually parse my file?
 
App.config is generally read only anyways. (right?) And shared by all users.

If you had VS 2005/VB.NET there is a new My.Settings which supports this out
of the box. (cool!)

Otherwise there is a lot of options. The simplest (for me) was to save all
settings in a class and just serialize it to disk as an .xml file in the
user's profile directory.

I've am currently using the approach described here:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnadvnet/html/vbnet07082003.asp

Greg
 
Greg said:

I used this approach a long time ago, but gave up after a while. The
problem is that it is re-inventing the wheel, the code essentially loads
an XML file, parses it for data which it then stores in memory. When you
access data you do so through the in-memory collection, when you want to
save values the XML file is written item by item.

It is far simpler to use the XmlSerializer class. The simplest way to do
this is:

1) create an XML class with example data that you want serialized
2) use xsd to create a schema file
3) use xsd to generate a code file from the schema.

the class can then be serialized and deserialized with XmlSerializer.

This does mean that you need to have a fixed schema for the
configuration, but this can be thought of as an advantage. After all,
your code will be written to expect only fixed configuration settings,
and so your code will only work with that version.

This is a much better article, in particular the comments about isolated
storage.

Richard
 
ummm... confusing to your users? they shouldn't be looking at it
anyhow (by default, most of them won't even see the extension in
Windows Explorer).

I think that's a crazy default option - imagine someone who knows how to
use a computer (eg, you) seeing a file list like this:

MyApp
MyApp.exe

In actual fact, the first one is called "MyApp.exe", and the second one
is a .config file!

(And in addition, it doesn't make people think about what they're
opening - an exe is the same as a txt in their eyes!)
 
Hi,

I think that's a crazy default option - imagine someone who knows how to
use a computer (eg, you) seeing a file list like this:

MyApp
MyApp.exe

In actual fact, the first one is called "MyApp.exe", and the second one is
a .config file!

(And in addition, it doesn't make people think about what they're
opening - an exe is the same as a txt in their eyes!)

You are forgetting the icon in front of it, they will see the real exe with
the app icon they are used to see and they will see the config file with
either a notepad icon or another not very familiar icon

In the worst case it will only takes them two tries to find out the correct
one
 
Ignacio said:
You are forgetting the icon in front of it, they will see the real exe with
the app icon they are used to see and they will see the config file with
either a notepad icon or another not very familiar icon

In the worst case it will only takes them two tries to find out the correct
one

And if someone (eg. a virus) writes an application called "My CV.exe"
into My Documents, which has a Word icon (since apps can have their own
icons), that's not very secure. The user opens My Docs to see a file
called "My CV" with a word icon. A stupid user isn't going to check the
details, they'll just double click. I just think "hiding" what will
happen when you double-click is a silly idea!
 
Regular home users actually get confused by extensions... This is why
it's default - Once someone knows about extensions they can easily turn
them on...

this however has gone completely off topic
 
Benny said:
Regular home users actually get confused by extensions... This is why
it's default - Once someone knows about extensions they can easily turn
them on...

this however has gone completely off topic

As most things do in here :-)

I personally believe things should be secure (I'd say not being able to
tell the difference between .doc and .exe a security risk!) by default,
and user friendly by option :)

Anyway...
 
Back
Top