I'm creating an application and I make use of Properties.Settings to store the settings.
However, let's say my application is on the desktop of the user and is called Program.exe, now, when the user copies this executable and places it somewhere else or even renames it, all settings are gone.
Why is C# doing this? Is there any way this can be turned off while pertaining the user scope? I don't wish to use the application scope since multiple users can be sharing the same computer.
The settings are likely stored in {appname}.exe.config which apparently is not being copied/renamed with the executable. Either copy the executable with the file, hard-code them in the application, or find another mechanism to get/set app settings (like the registry).
The application will look for these settings in a file titled {appname}.exe.config. If the executable is renamed (without renaming the .config file) or copied to another location without copying the .config file along with it, the application won't know where to look for their settings so they will be blank (unless you set a default value in the app).
You can "hard-code" default settings by putting a value in the Settings.settings "file" in Visual studio (which effectively adds the default value as an attribute to the setting).
Another option would be to hard-code the values directly in the source code. I'm NOT recommending this approach as it hinders the ability to change that value, but if you want to be able to deploy the app by just copying the EXE (and nothing else) then it is an option.
See http://msdn.microsoft.com/en-us/library/aa730869(v=vs.80).aspx for details.
The settings (and their location) when using Properties.Settings is determined by the Scope setting of the particular setting.
Settings that are Application scoped are in the app.config file (renamed at compile time to .exe.config - these settings are read only at run time), and settings that are User scoped are saved in a user.config that is tied to the user's profile on the machine (these settings are read/write at run time). By properly scoping your settings you should be able to avoid this type of problem.
Settings are stored in the user profile (under C:\Users[UserName]\AppData\Local), these settings are under folders that have the application name and also have an identifier of the location of the exe file they refer to, for example: MyApp.exe_Url_hpvvra0rj4y03ebpz3cfmzsrcpczat11, refers to the executable under Program Files, if i move or copy the exe and run it, it will create another folder with another URL (MyApp.exe_Url_vqzsq0spwewydv3wrnebtqji24nwuboe, for example), i haven't find a way to avoid this but a good workaround is to copy the settings from another config file, just note that this method is not foolproof as you have to choose the right file to copy the setting to and if you expect your exe to be copied or moved constantly this will be a hard task.
Another workaround is to simply create your custom settings class and put the file anywhere your application can find it and don't realy on the built in settings on .NET.
Related
I have written a C# app using Winforms, and am trying to utilise the inbuilt Properties.Settings (User scope) to remember user state between launches of the program.
When the app is deployed via Visual Studio's inbuilt Build > Publish, apparently this file is put into the Local Appdata folder.
However, I want to use NSIS to create the executable of the program. I am able to place the ProgramName.exe.config file into Local AppData, via NSIS script, but my app does not seem to read from it. No user settings persist.
Is this even possible? Or should I use my own method (database or write my own settings xml) to store user settings?
OK, I got it working with NSIS.
The App.config file has a property called "Copy to Output Directory" which was set to "Do not Copy" by default. I found this information here: https://learn.microsoft.com/en-us/dotnet/framework/configure-apps/
I found out where the user.config file was going to be created, with help from #Jimi by adding System.Configuration as a reference, and then getting the path using:
var config = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.PerUserRoamingAndLocal);
The user.config file is not created on application install, rather the first time that the following is called:
Properties.Settings.Default.Save();
There is nothing special that the developer has to do in NSIS.
My C# program has an app.exe.config file. User can install the program anywhere. If the user chooses to install the program in the "Program Files" folder, the program will have privilege problems modifying files in Windows 7, so I've externalized the files that can be modified to the AppData folder. Except app.exe.config file, that should also be modifiable by the program when user changes its settings. Apparently it should be in the same folder as where app.exe.
I think this is a quite trivial problem, however I cannot find the right solution.
Copying the config file elsewhere, modifying it and copying back to Program Files;
Creating a second config file elsewhere;
Not giving the user the choice of installation folder;
Forcing the program to be run as admin.
All of these solutions would lead to a bad design. What solution wouldn't?
EDIT: Maybe some of my premises are wrong and it is possible to have the config file installed to AppData or anywhere else without changing the executable's location. I haven't yet found for sure if this is possible, however.
The Application Settings Architecture should help you - you can define user settings as well as application settings that are stored in a user.config file.
Reference to MSDN: http://msdn.microsoft.com/en-us/library/0zszyc6e(v=vs.110).aspx
"Non-default user-scoped settings are stored in a new file, user.config, where user is the user name of the person currently executing the application. You can specify a default for a user-scoped setting with DefaultSettingValueAttribute. Because user-scoped settings often change during application execution, user.config is always read/write."
Change app.config file permissions upon installation. If you are using WIX (I'm just assuming since it's the most popular solution nowadays) have a look at http://wixtoolset.org/documentation/manual/v3/xsd/util/permissionex.html
I want to save settings permanently in the exe file
I use this code
Settings.Default.WindowSize = this.Size;
Settings.Default.Save();
I'm having one big problem with this if the file path change all settings are lost.
Like if you have the exe on a flash drive and you put it in different PC the settings is gone.
Is there a way around this. OR is there a different setting/parameter I can use?
You can't save settings in an exe file. Settings.Default.Save() doesn's save settings into an exe file. That's what configuration files are for. If you want to bring the settings with you, copy the configuration file as well.
Of course, saving configuration next to exe files is outdated, and considered bad practice, not to mention being insecure (and Vista+ will not allow you to do it without administrator privileges inside of Program files). The configuration will endup in your user folder, so that it doesn't affect other users of the application.
You could use the registry, but that only helps when you move the EXE on a single machine. Best thing is Luann's answer, copy the accompanying config file.
A purely transportable EXE would store it's settings "in the cloud"
I need set hidden .exe.config that actually resides in application folder. Alternatively, it would good change folder location, example in application data (hidden folder).
You cannot change the location of the app.exe.config file with the default CLR host. It initializes the primary appdomain with the values it finds in the .config file before your code starts running. There's only one place it will look for the file, in the same directory as the startup EXE, using the name of the EXE. Altering the location is technically possible but only if you write a custom CLR host that uses a custom AppDomainManager. Writing a custom CLR host requires COM code written in C++. This otherwise defeats the point of having only a single deployable file.
If you intend to do this to hide sensitive information, like the username+password for a dbase connection string, then keep in mind that security through obscurity is not true security.
If you intend to do this to achieve single-file deployment then don't forget to overlook the standard solution: a single file named setup.exe
I thought it should be a config file, but cannot find it.
thanks
The whole config file location can be a bit slippery. Depending on whether or not its a "user" setting or an "application" setting, it will go into a different file. Some settings can even come from your "machine" config (Like in the case of ASP.NET). Instead of guessing where everything is, I find it much more useful to ask .NET where it is looking for these files. Roughly:
//Machine Configuration Path
string path1 = ConfigurationManager.OpenMachineConfiguration().FilePath;
//Application Configuration Path
string path2 = ConfigurationManager.OpenExeConfiguration(
ConfigurationUserLevel.None).FilePath;
//User Configuration Path
string path3 = ConfigurationManager.OpenExeConfiguration(
ConfigurationUserLevel.PerUserRoamingAndLocal).FilePath;
App.Config
This is what gets added to your project. The build process will name it [myproject].exe.config. This holds the (mostly) read only application settings and the application-level defaults for user-specific settings. Application level settings are difficult to programmatically change their values. Application level setting properties will only have "get" defined. The intention is: if your setting is for all users of the application, then a manual edit (or the installer) should set them. If it changes per user, then make it a per-user setting.
Binary Default Settings
Your application will run without its [myproject].exe.config file. To do this, the binary has its own version of the file "stored". This is useful in some ways, but can be confusing. If you have a .config file in the wrong place or with the wrong name, .NET reverts to the "binary defaults". It can cause the appearance of not being able to affect the settings by changing the config file. Use the method above to know where the .config REALLY goes, or face the wrath of the binary default settings.
User.Config
This is generated the first time you "save" your Default.Settings object with a "per-user" setting. This file is saved in the user's profile path in a location based on your project's name, version, operating system, and some other dark .NET magics. The properties for these settings are readable/writeable. They are designed to be easily set and then saved with a single call.
Pulling it Together
So where do my settings go? The answer is that potentially many files are joined together to get the "Active set" of settings. App.config and user.config settings are the basic blocks, but there are machine.config settings, and then there are dependency assembly settings that can further complicate things...but thats another topic entirely.
The real truth of config files is spread across a lot of ugly cases and details. However, with a little knowledge about how they are joined together, it is a fairly useful system. Especially if you realize you can databind to these settings ;)
If you're talking about .Net settings, then they will normally be in a .config (xml) file in the same directory as the application. When you save them, however, a local copy gets saved in to a user writable folder (typically C:\Users\username\AppData\Local under Vista). Under XP, look in the Documents and Settings folder.
The .Net application uses this file in preference to the 'default' one in the application directory.
Hope this helps.
On Windows XP, it's stored in a file called user.config in a subfolder of:
C:\Documents and Settings\username\Local Settings\Application Data
http://dotnetproject.blogspot.com/2006/08/where-is-userconfig-file-located-in.html
Are you referring to the .settings file in your application? When you add values to that file, an app.config file gets created for you. You should be seeing it in your solution explorer.