tags:

views:

40

answers:

3

Alright, so I know about the Settings.Properties.Default.* Stuff, but thats not what im trying to use.. I'm trying to develop my own class, ill show you:

public sealed class SettingsHolder<T>
{
   public SettingsHolder(){}
   public T Setting
   {
      get{ /*return setting*/ }
      set( /*store setting*/  }
   }
}

so then i could compile that to a dll, and reference it in an application, and do something like this

SettingsHolder<string> stringHolder = new SettingsHolder<string>();
stringHolder.Setting = "hello world";

and on next application launch

string welcome = stringHolder.Setting;

and welcome should = "hello world".. is this at all possible? i had origannally tried to disect the actual properties.settings class, but with no luck

+1  A: 

I don't think that's possible. The setting data has to be stored somewhere, in some file or database (when you compile your app you have .exe.config file).

Mr. Brownstone
would it be possible for my class to generate a dll or other to store all the settings being used in that app?
Tommy
+3  A: 

The .NET/VS settings framework already does exactly what you indicate that you're trying to do, without the clumsy runtime casts and generic classes. Absent a very compelling reason not to use it, that is what you should use. It already handles persisted user-level settings.

If for some reason you absolutely cannot use that, either store the settings directly in a file somewhere in the user's AppData, or use Isolated Storage. You will have to write your own persistence model for it.

If an application could rewrite its own executable code on disk, it would raise all sorts of thorny questions about security and reliability. Besides, security restrictions on Vista and Windows 7 would prevent it from functioning correctly anyway - unless it's a ClickOnce app, it's probably installed in a program folder (i.e. Program Files), and you'd need a user with administrative privileges to elevate the process in order to make it work.

Aaronaught
+1 For deployment thoughts, this has bitten me before.
Leigh Shayler
A: 

Whe you do new classname() you create the object with members of that class initialised in memory to their default values. e.g. if your SettingsHolder class contained an int _n; it would be initialised to 0. Alternatively, you can of course initialise your member variable to a specific value, e.g. int _n = 5;

As far as I recall, this is in the definition of the language, which therefore precludes what you suggest; which is essentially something along the lines of 'self-modifying code with state'.

Therefore, you do need to use mechanisms to store state in your programs - such as Properties.Settings (which saves to XML config files by default), or a DB for example.

You don't really need to dissect the Properties.Settings class. If you access Settings from the project properties menu, and add a 'User' or 'Application' setting. It can then be accessed with Properties.Settings.Default.SettingName. You do need to instruct the code to save changes to the properties, if I recall correctly.

Nij
It would be appreciated if down-votes would be explained with a comment!
Nij