views:

809

answers:

2

This seems like a simple question but the intergoogles have not been kind.

I have a C# desktop application. There are certain properties that need to be customized per customer, such as each customer's organization's name, that are otherwise independent of the actual functionality of the application and therefore do not need to be compiled into it.

What is the best/preferred method to pull this data out of the application, manage it in VS (2008), and deploy it to customers' desktops?

For example, say I have two separate users in two separate organizations, so they each need a separate set of settings. Do I just create a new app.config file for each of them? Would I have to rebuild the setup project for each user in order to accommodate that new app.config file?

thank you

+2  A: 

You could store that type of information in the App.Config file, in an INI file, or in the registry on the target system.

Depending on the method you decide on, there are lots of sample code available:

C# App.Config files

C# INI files

C# Registry access

BoltBait
Thank you for your responses. So, say I use app.config - what is the mechanism for distributing different app.config files to different users?
If the data you are looking for doesn't exist, prompt the user for it then save it for next time.
BoltBait
+2  A: 

The Application Settings subsystem allows you to create strongly-typed settings, on a per-user or per-application basis. Just right-click the project, choose Properties, and click on the Settings tab.


From Application Settings Overview:

Application settings addresses both needs by providing an easy way to store both application-scoped and user-scoped settings on the client computer. Using Visual Studio or a code editor, you define a setting for a given property by specifying its name, data type, and scope (application or user). You can even place related settings into named groups for easier use and readability. Once defined, these settings are persisted and read back into memory automatically at run time. A pluggable architecture enables the persistence mechanism to be changed, but by default, the local file system is used.

Application settings works by persisting data as XML to different configuration (.config) files, corresponding to whether the setting is application-scoped or user-scoped. In most cases, the application-scoped settings are read-only; because they are program information, you will typically not need to overwrite them. By contrast, user-scoped settings can be read and written safely at run time, even if your application runs under partial trust. For more information about partial trust, see Security in Windows Forms Overview.

When you add a setting, Visual Studio creates a strongly-typed property in the settings class. It also creates an entry in the application config file. For an Application setting, this is the actual value of the setting. You could change it at installation time, if you like. For a User setting, this is the default value of the setting. The user can change the value at runtime. You can then call the Save method to save the changed value. The current value of User settings is stored in a user.config file stored in the correct per-user folder, based on whether the user is roaming, local, etc.

It's really very nice when used with Windows Forms, since various properties of forms and controls can be bound to application settings at design time. This means that when the application starts, these properties will take their initial values from the settings. If the values change at runtime, the settings will change. You can then save the changed settings before the application exits. They will then automatically be used when the application starts again. This takes very little code.

Even though these were created for Windows Forms in .NET 2.0, I've used them with other project types, especially unit test projects. Of course, in that situation, you have no per-user settings.

John Saunders
Thank you for your response. I edited the question with an example. I am a bit familiary with the Application Settings subsystem. Say I use app.config - what is the mechanism for distributing different app.config files to different users when they install the application?