All, I have a large application. This application uses a .config file to deal with its various settings. This is fine in development, and the .config file is found and working happily in the respective \bin folders (Release and Debug). I have written a NSIS installer an I am now running the app; it is working perfectly, saving settings, restoring settings and generally being a good LAD.
However, the 'MyApp.exe.config' is not where the settings are being written (I have checked and even deleted this so it could be recreated). It is also not in ...Users\Me\AppData\Roaming\MyApp?
Where the Devil is my applications config file?
Thanks again for your time.
Edit. I have printed out System.Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData) and this points to the Roaming AppData directory above.
The configuration system for .net gets its settings from several locations.
General config comes from:
The first location is the machine.config file that ships with the .net framework.
The next location is the application's configuration file.
Next the settings API gets values from (using the default provider):
Hard-coded defaults when the app was compiled.
The application configuration file.
The user's settings file.
If the application's configuration file does not exist it will not be automatically created (doing so would be pointless since it would only contain the defaults the application already knows).
Saving the settings will however create a new user settings file as normal.
Related
My C# DLL project has settings and the defaut values are held automatically in the xxx.dll.cong file.
When I perform a save of the settings:
Properties.Settings.Default.Save();
They are correctly read back in when I display my form. But I can't work out where the users saved version of the config file is kept? I tried to look in %localappdata% and nothing is there.
To summarise:
This is a .Net DLL tool bring run inside BricsCAD.
We are using the Properties.Settings concept.
Where is the users Save() version of the file kept?
Update
This is the closest conversation I could find about this subject (related to AutoCAD). It is still relevant because my tool is used by three CAD packages:
AutoCAD
BricsCAD
ZWCAD
But the linked discussion does not actually answer my question. Clearly the "settings" are persisting. But they are not persisting in the %localappdat% folder for my tool. I have now tested with both BricsCAD and ZWCAD and still can't find them.
According to this article the configuration file should be updated. But the config file where the DLL is is not updating. Even though the mechanism works. The persisted settings are somewhere else.
I decided to use the MS-DOS command findstr in a console window:
findstr /s "SaveToDXF_DuplicateCreateCount" *.config
I performned the test on my C drive and it came up with three files and one of them seemed to be the file of interest:
c:\Users\[USERNAME]\AppData\Local\Bricsys\DefaultDomain_Path_LOTSOFCHARACTERS\21.2.06.0\user.config
The LOTSOFCHARACTERS was a weird sequence of text. But when I open that user.config file it had my current settings.
I am not sure as the the reason for my settings being persisted in this manner.
This answer (https://stackoverflow.com/a/60117461/2287576) prrovided to a differeht question actually explains the aforementioned. To quote:
User Settings (Settings in the User scope) (applies to Visual Studio
2017+) These settings are stored along with the Application settings,
but have associated local storage files, used to store values that a
User (or the Application) can change at run-time:
2.1 A user.config file stored in the current User profile in the
[User]/AppData/Local/[CompanyName]/[ProductName].exe_<hash>/[Assembly Version]
section, if the setting's Roaming attribute is set to false.
2.2 A user.config file stored in the current User profile in the
[User]/AppData/Roaming/[CompanyName]/[ProductName]/[File Version]
section, if the setting Roaming attribute is set to true instead.
Is there a need to have a config file when using User Settings? I tried creating both User and Application settings then using them both in my code (including saving a change to the User setting). Then I deleted the config file and ran the .exe
Low and behold User Settings work just fine without the config file. So do Application Settings. Their initial values are taken from what was set in the Settings.settings designer.
However, the Application Settings can't be changed without the config file (meaning a config is needed for connection strings and installation setup), but for a smaller application with no installation needed we shouldn't really have to make the user change the config file themselves for setting changes.
As for the User Settings, their changes are saved to a separate config file stored in Local AppData...
So for these circumstances is a config file needed when using these settings?
Properties.Settings.Default.UserTitleColor = System.Drawing.Color.Green;
Properties.Settings.Default.Save();
The config file is there to change the defined (default) values during compilation.
You are right that if the file is not there, the values are taken out of the assembly and the values defined at compile-time are used.
But to be able to change them without re-compilation the config file can be used.
A default use-case for that is connections-strings to databases: They are often in the "Application" scope, but need to be changed for each installation.
I heard that for C# programs,
App.config —This file contains configuration settings that the application reads when it starts.
For applications compiled from C programs, they don't always read some files in a specific directory. Whether that happens is up to the applications.
Is the arrangement of an application reading App.config in a particular directory done by the compiler?
Is the arrangement specific to Visual Studio IDE or compiler?
If the application is compiled not within Visual Studio, will the arrangement still hold?
Thanks.
Good question. As I understand it, the reading of the configuration is handled by classes in the System.Configuration namespace, and by convention they search for the .config file in the same directory with the same name as the executable you are running. You can use System.Configuration's ConfigurationManager to open arbitrary .config files, but that's uncommon in my experience.
From the link:
Executable–hosted app.
These apps have two configuration files: a source configuration file, which is modified by the developer during development, and an output file that is distributed with the app.
When you develop in Visual Studio, place the source configuration file for your app in the project directory and set its Copy To Output Directory property to Copy always or Copy if newer. The name of the configuration file is the name of the app with a .config extension. For example, an app called myApp.exe should have a source configuration file called myApp.exe.config.
In several C# projects I have been using an app.config file to pass various settings to my program, settings like connectionstrings, power levels etc.
However sometimes I have come in situations where the settings aren't updated as expected and I have concluded that I am not that well informed with the proper use of app.config file.
Example:
Replacing the .exe file with a new version (where settings are different) to the output directory without changing the exe.config, results in the program seeing the hard-coded settings and not the settings of the existing .exe.config
So my Questions are:
What is the exact role of exe.manifest file
Every time I create a new .exe do I have to paste in the output folder anything else except the .exe file?
Whats the difference in obtaining the setting value by: ConfigurationManager.'settingName'... rather than:
Properties.Settings.Default.'settingName'?
What is the role of app.config build action?
Sorry If I am asking too much in a single Question.
The app.config file is a file that gets a special treatment when running the associated application. If you executable is named MyApp.exe the app.config file should be named MyApp.exe.config. The role of the app.config build task is to copy the file named app.config in your project to MyApp.exe.config in the output directory.
.NET provides ways to read the contents of the file (it is in XML format) and various parts of .NET will look for different sections in this XML to provide configuration.
A widely used section is the settings section you refer to as Properties.Settings.Default. This section plays together with Visual Studio that provides an editor for application settings. The settings are accessed in the code by using a generated class. Adding a setting will add a property to this class and this property is initialized from a value in the app.config file.
In the Visual Studio editor you can set a value for the setting and you can think of this as a default value for the setting. However, if you overwrite the value in the app.config file the later will take precedence. This allows you to modify the app.config file after installation and rerun the application with a modified setting.
You can also access application settings the app.config file using other methods, but in my oppinion using the Visual Studio editor and the code generated class is the best way to do that.
I am not sure I fully understand the problem that you experience. If you update MyApp.exe and leave MyApp.exe.config intact you should not see a change in the settings used by the application (unless of course you have renamed or changed some settings).
The manifest file provides information about side-by-side assemblies and can be used to request elevated privileges among other things. This is not related to the app.config file.
There quite a few resources about that.
See http://msdn.microsoft.com/en-us/library/ms229689%28v=vs.90%29.aspx
and the (better) overview: http://msdn.microsoft.com/en-us/library/k4s6c3a0%28v=vs.110%29.aspx
app.config is a very powerful tool. It addresses many issue like versioning, migration, upgrading etc. but this requires some in-depth reading from the links above.
Maybe one thing you could do, if you want to copy only .exe file every time you build your app, is make a settings.ini or settings.txt file, put your parameters in this file (that are not secret of course) and read all your settings from there when you start your app.
You can put all your connection string logic in your login form if you have one...
Kind of a two part issue.
I developed an app which reads from and writes to an App.config.
The application is installed in Program Files by my MSI installer.
It works fine on my Win7 computer but I have users on Win7 that get Access Denied when writing to this App.config.
I am writing to the app.config using the below code:
Configuration config = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);
config.AppSettings.Settings["Endpoint"].Value = endpointTxtBox.Text;
config.Save(ConfigurationSaveMode.Modified);
Why don't I get this issue on my development pc? I have tried both with a local admin and normal local user account.
How do I relocate the App.config to an unprotected directory?
Cathal,
You should not have to move the app.config in order to let your users save their application settings; .NET already has support for saving user-scoped app settings in user-writable storage baked in! You can even specify the default user settings in the app.config file.
Check this link for details:
http://msdn.microsoft.com/en-us/library/8eyb2ct1(v=vs.110).aspx
Note that making use of a strongly-typed .NET Settings class rather than the raw, more weakly-typed AppSettings NameValueCollection. (The settings can still stored in the app.config, though.)
You can create a Settings file in VS (the template is called "Settings file" in VS).
A couple of things confused me about Settings files at first, so I thought I would point them out to you:
1) First: the .settings file. The VS designer lets you define your app settings, their types, and their scopes (i.e. user or application). This is the file the designer modifies when you user the designer, but runtime configuration changes will never be written to this file. It defines your app settings and their default values. That's it. I didn't get that at first when I was trying to wrap my head around Settings files.
Also, notice that the build action on the .settings file is set to SettingsSingleFileGenerator.
2) The .designer.cs file. VS/MSBuild generates this file at build-time for you because the build action on the .settings file is set to SettingsSingleFileGenerator. The class that it generates is a strongly typed wrapper for your configuration properties, and you can use it equally well for your application-scoped and user-scoped properties.
3) The runtime settings that your Settings class wraps are still stored in the app.config.
4) User settings are stored underneath that user's AppData\Local directory so that they have full read/write permissions.
I had a couple of other ideas, if what you need to do really is let the user modify the global application settings for all users.
Externalize some of your configuration by using the configSource attribute. You store the entire
appSettings section, for instance, in a separate file by doing this:
<appSettings configSource="....\file.config" />
Here are the docs for that feature: http://msdn.microsoft.com/en-us/library/ms228154(v=vs.85).aspx
I believe you can manually load a config file anywhere you want using the System.Configuration.ConfigXmlDocument class. Construct one using the no-arg constructor and then call its Load(String filename) method.
Store your configuration in the registry rather than the filesystem by implementing a custom SettingsProvider.