I have a program which I'm going to deploy using the package for deployment built into VS.
Now I have an app.config file which I want the user to be able to modify (even after running the program), but I have no idea where exactly the installer dumps the files, and I'm not expecting the users to root around their filesystem.
What I was thinking is - I ask the user to specify some directory (which needs to happen anyway since its a game) - I check for the config file there, and if its not there, I copy it from the root directory the program can see - then read the one in the 'save' folder.
That said, its sounding like a very ugly and hacky solution - is there a better one?
In this blog I show a different approach which uses a configuration file which can be changed externally. The values read from the file are properties (key value pairs). If we make changes to the file they are reflected during run time without the need to restart the application.
If you want to change web. config files you can use the Azure portal, there is a tool called "App Service Editor" in preview or Kudu that lets you edit any of the files you've deployed.
config ? The web. config files specify configuration settings for a particular web application, and are located in the application's root directory; the machine. config file specifies configuration settings for all of the websites on the web server, and is located in $WINDOWSDIR$\Microsoft.Net\Framework\Version\Config.
I wouldn't be encouraging users to modify the app.config. The app.config is copied into the same directory as your app exe and usually contains settings which your app depends on to run correctly e.g. DB connection strings, system defaults etc. Your playing a dangerous game by letting users change settings in there directly.
A safer approach would be to export another XML file into the users documents folder where they can override app settings. Have your app load in the app.config first then override those values with any settings found in the users own config file.
I would also recommend implementing some sort of UI for this, even if its really basic. Your average user isn't going to be comfortable editing XML directly, too much margin for error.
You could use the application (or user) settings to persist any changes that the user might want to make in the configuration. See the ApplicationSettingsBase
class and this article.
Say your application contains a user setting called Score
, managed internally by a class called MyUserSettings
:
public class MyUserSettings : ApplicationSettingsBase
{
[UserScopedSetting()]
[DefaultSettingValue(0)]
public int Rank
{
get
{
return (int)this["Score"];
}
set
{
this["Score"] = value;
}
}
}
You can save the current values, usually when the main form is closing, using the Save
method:
myUserSettings.Save();
If you want users to modify some settings directly, you can use a property grid or your own form that binds the instance of MyUserSettings
class.
If the settings are marked as "User", then the values would be stored in the user.config
file, in %InstallRoot%\Documents and Settings\username\Local Settings
or %InstallRoot%\Documents and Settings\username\Application Data
(for roaming profiles).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With