Application Settings

  • Thread starter Thread starter WineNCheese
  • Start date Start date
W

WineNCheese

I'm just venting.

I finally got around to converting a big WinForms app for my biggest client
to .NET 2.0. I've heard all along that application settings are now
writable, which has always been one of many bones of contention with .NET
1.1 for me. So I get to the point where I am going to convert my custom
settings mechanism, do a little investigation, and find out the reason I
made a custom configuration file mechanism hasn't changed at all. Sure -
you can write user setttings, and settings are type safe now, but the
application scope settings are still read-only. (If anybody knows a
reasonable workaround that works within the framework for this, I'd like to
hear it). I certainly understand MS's reasoning for making them read-only,
but I'm more of the mind that in "most cases" the application settings
shouldn't/wont need to be written. However, to prevent it altogether is
simply stupid, imho. I feel like I'm old enough to be responsible for my
own actions by now.

I do like the new stuff for user settings and for application settings that
don't change, so I'm actually going to use the new stuff for all of that.
However, I have one setting that all users must be able to change, and must
be the same for all users. I had a custom configuration file, and I allowed
write access to its containing folder on installation. I may move this
value to the database for now. Or, Gawd Forbid, the Registry!

Don't get me started on generic collections! Ok, I'll start, but just
barely... Ha! Have you seen the Find() or Exists() method on List? Here's
the code to find '6' in a list of ints:

List<int> myInts = new List<int>();
myInts.Add( 0 );
myInts.Add( 1 );
myInts.Add( 2 );
myInts.Add( 3 );

int n = myInts.Find( delegate(int x) { x==6; } ); // seems rather obtuse
to Find(6), doesn't it? This returns '0'! Ha!
int m = myInts.Find( delegate(int x) { x==0; } ); // This returns '0' too!

I tried deriving my own collection, and quickly found that two values of
type T cannot be compared. I'm sure there's a good reason for this - I just
hope there's a better workaround eventually. It makes me wish for the days
#define!

Even though that's just the tip of the tip of the iceberg of my complaints,
I still like it (2.0 that is). It's definitely a step in the right
direction.
 
Here is my 2 cents on Settings Information.... i.e the scenario that MS
gives is for settings, not preferences. What you are wanting to give the
users to change, is a preference. This has to be allowed to change by the
user and stored in a location where the program has access to write and you
don't to worry about administrators preventing access etc.... now XP has a
great directory organization that you can leverage on to provide this for
each logged in user.. so Write your file to some directory like below...

<My Documents>\<Company Name>\Application Name>\file.info

file.info, can be a XML file or any file that will have user preferences...
this is per XP login so each logged in user can have their own setting. This
location is writeable for all users ( no administrator will prevent access
to My Documents location for a user - not the intent), no privileges
problem, no need to registry information/access etc. This probably I feel is
the cleanest way to do. Also if you keep this file in XML format, you can
transport to the DB and get it down to the same user on a different machine
when they login with less effort...

You can read the My Documents location as below

Environment.GetFolderPath(Environment.SpecialFolder.Personal)


HTH
Vijay
 
I'm just venting.

I finally got around to converting a big WinForms app for my biggest client
to .NET 2.0. I've heard all along that application settings are now
writable, which has always been one of many bones of contention with .NET
1.1 for me. So I get to the point where I am going to convert my custom
settings mechanism, do a little investigation, and find out the reason I
made a custom configuration file mechanism hasn't changed at all. Sure -
you can write user setttings, and settings are type safe now, but the
application scope settings are still read-only. (If anybody knows a
reasonable workaround that works within the framework for this, I'd like to
hear it). I certainly understand MS's reasoning for making them read-only,
but I'm more of the mind that in "most cases" the application settings
shouldn't/wont need to be written. However, to prevent it altogether is
simply stupid, imho. I feel like I'm old enough to be responsible for my
own actions by now.

I do like the new stuff for user settings and for application settings that
don't change, so I'm actually going to use the new stuff for all of that.
However, I have one setting that all users must be able to change, and must
be the same for all users. I had a custom configuration file, and I allowed
write access to its containing folder on installation. I may move this
value to the database for now. Or, Gawd Forbid, the Registry!

Don't get me started on generic collections! Ok, I'll start, but just
barely... Ha! Have you seen the Find() or Exists() method on List? Here's
the code to find '6' in a list of ints:

List<int> myInts = new List<int>();
myInts.Add( 0 );
myInts.Add( 1 );
myInts.Add( 2 );
myInts.Add( 3 );

int n = myInts.Find( delegate(int x) { x==6; } ); // seems rather obtuse
to Find(6), doesn't it? This returns '0'! Ha!
int m = myInts.Find( delegate(int x) { x==0; } ); // This returns '0' too!

I tried deriving my own collection, and quickly found that two values of
type T cannot be compared. I'm sure there's a good reason for this - I just
hope there's a better workaround eventually. It makes me wish for the days
#define!

Even though that's just the tip of the tip of the iceberg of my complaints,
I still like it (2.0 that is). It's definitely a step in the right
direction.
Click to expand...

What is your question?

Good luck with your project,

Otis Mukinfus
http://www.arltex.com
http://www.tomchilders.com
 
Vijay,

I appreciate your response, but unless I have misunderstood you, this has nothing to do with what I need (and it's also somewhat wrong).

I want read-write Application Scope (NOT User Scope) settings (NOT preferences).
Writing a file to a user specific directory is by definition a User Scope solution, and therefore of no use whatsoever.

Also, contrary to your first paragraph, what MS has given us works perfectly for user preferences or settings. In fact, it works perfectly for all settings and preferences at the application and user scope, unless you have application scope settings that you would like to be modifiable (read-write).

Finally, use of an XP directory scheme for user settings/preferences (while no longer needed with the settings capabilities in the Configuration namespace) is fine if you know your user will be using XP. It would be suicide for this product to make this assumption.

WNC
 
What's my question? None really. Just like the first line says - just
venting.
Good luck to you as well!
 
Back
Top