I want to save User-Settings with Visual Studio 2015, that don't reset after ending the application. For example you can choose the language and on the next startup of the application the settings are loaded. Is this possible without using external Files, StreamWriters and so on?
You could use application and user settings as described in this MSDN tutorial
There is a distinction between app settings which are readonly at runtime, but valid for all users on the machine, and user settings, which can bei changed, but are only valid for the respective User.
You can create them via VS in the project properties -> settings. You use them in Code via
var x = Properties.Settings.Default.MySetting;
See the tutorial for further Details.
Related
I'm using Settings.Settings to store settings at run-time. It was very helpful for my earlier application to store data. But in my current project its not saving the settings data. My application have some tab and each tab contains some TextBox. Im using textBox Text to store string values.
Properties.Settings.Default.Setting1 = textBox2.Text;
Properties.Settings.Default.Save();
It is a working method for my all previous application.But I can't understand why its not working in my current project.
Since your question does not include many details, I've tried to answer as much as possible:
Try to perform a Properties.Settings.Default.Upgrade() and then saved settings get loaded.
You have to call the Upgrade method of ApplicationSettingsBase derived class (that is normally called Settings and is created for you by Visual Studio)
Properties.Settings.Default.Upgrade();
When/where to call the Upgrade method? There is a simple trick you can apply: define a user setting called UpgradeRequired (example) as bool (the easiest way is through IDE). Make sure its default value is true.
Insert this code snipped at the start of the application:
if (Properties.Settings.Default.UpgradeRequired)
{
Properties.Settings.Default.Upgrade();
Properties.Settings.Default.UpgradeRequired = false;
Properties.Settings.Default.Save();
}
So the Upgrade method will be called only after the version changes and only one time (since you disable further upgrades by setting UpgradeRequired = false until a version change - when the property regains default value of true).
Check the scope of your settings [USER/APPLICATION]
Try this out, and if it doesn't work check the below conditions.
Also, a more detailed question next time would be much appreciated.
Permission (NTFS permission)
Or Active directory permission
Or capacity of windows drive is full.
Or there exist two or more user folders and you checked another.
For example: There are two or three folders, user.domain, user.workgroupname, user.
Despite all this, I suggest you to learn about System.Reflection and develop your personalized method to save settings, the option provided by the Visual Studio isn't very dependable.
Hope this was helpful.
I want to get and set some application settings hidden for the user. In this case these are two tokens and two tokens that are being altered by the application. But still all four them are a secret to the application user.
I found two ways on MSDN and this forum.
Use a .config file. -> this sounds okay and I can change some values in it. But I see still a plain text file after publish.
Use the settings in the project properties. -> should it be? I read warnings about that this not so secure after all.
A lot of sites describe a web server solution while I just want to have a desktop solution.
Btw. It is not a commercial product, I am making a hobby project to learn more from C#.net.
If these files need to be altered by the application, you will need to persist these outside of the application so that the new settings will be loaded next time the app starts.
For this, you can always create a config (or settings) file and hide it in the System.IO.IsolatedStorage files for the assembly. This is still editable by the user, but its a bit of a pain to find - plus this will transfer over with roaming profiles so that the settings are used cross machine.
Something simple to help you start out:
IsolatedStorage.IsolatedStorageFile storage = IsolatedStorage.IsolatedStorageFile.GetUserStoreForAssembly();
string subdirectory = "SomeDirectory";
storage.CreateFile(System.IO.Path.Combine(subdirectory, "settings.config"));
Does the * existence* of the setting need to be kept secret, or just its value?
If the latter, I'd suggest encrypting the value you save to the .config file.
I'm implementing a new class library's settings and I'm wanting to use .NET 2.0's settings architecture, instead of the regular appSettings section in a .config file.
I've created a Main.settings file through the Visual Studio 2008 IDE, and this has autogenerated both the Main.settings file and a corresponding Main.Designer.cs file. In the IDE, I have to select between whether each setting should have User scope or Application scope, which translates to the IDE applying either UserScopedSettingAttribute or ApplicationScopedSettingAttribute to the setting's Property.
The stuff on MSDN I've found on the topic seems to come at things from the point of view of a Windows Forms application; it talks about using user-scoped settings for stuff which pertains just to the user using the app, and application-scoped settings for stuff which always pertains to the app, no matter which user is using it.
However, what should I do when my settings file isn't for a Windows Forms app, but for a class library that I'm calling from a website under IIS? Does it matter whether I scope the settings as User or Application? If so, what factors are there to take into account as to how I should scope the settings?
Web applications do not support user scoped application settings. To get similar functionality, you could use the SettingsProvider class or create your own implementation of it. For application-wide settings, you will have to use the web.config file and either
Utilize the appSettings section and use System.Configuration.ConfigurationManager to access those settings, or
Implement your own ConfigurationSection.
The answer to your second question is: it depends.
In a web app, user-scoped settings are usually associated with a session and allow for each user to have a different value for a particular setting. These settings are usually used to customize a user's experience. On the other hand, if you want a setting to be the same application-wide regardless of the user who is accessing the application, you should be using an application-scoped setting.
If you provide more detail regarding your specific situation, I may be able to provide further guidance.
Also, take a look at this question if you want to use a config file from the class library instead of placing your settings in the web.config file.
I want to add new settings to the user.config at runtime for a C# application (WPF).
These settings will be added by independent modules so I have no idea what they will be in advance.
Most examples refer to:
Configuration config =
configurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);
But this only allows you to access the Application Settings
and you can't save it anyway as it's not meant to be modified.
I want to be able to do something like
Settings.Default.Add("SomeKey", "someobject");
Settings.Default.Save()
after which this setting would be available the next time this specific user
starts the application.
You may wish to check this solution.
It is doable but it is lots of code.
I've been trying to modify my application to deploy and update using ClickOnce. I've managed to get the program working but I'm having trouble with the program configuration. My program uses a custom XML configuration file located in the application directory. This raises 2 major problems.
1.) The configuration file is very hard to get to. Without knowledge of how ClickOnce works the user will not be able to locate it.
2.) Currently if I change the configuration file ClickOnce automatically "updates" the configuration file to the original version, destroying my configuration.
Ideally I would like it to move the configuration file to another location and create a start menu shortcut to it next to my application. But if I change the program to do this can I still deploy the application using ClickOnce?
Thanks in advance,
Fr33dan
Why don't you put a copy of the configuration in the users app data folder (this can be done on first run) - then have a button in your application which opens it (either externally or in your application)?
You can always store your configuration data in the Application Settings. This won't get overwritten on every ClickOnce change or update (unless you change the Type of the setting). You can then create a simple form to update it. That's the technique many .NET developers use for screensavers.
There are a number of things you can do here to mitigate this as a problem.
Firstly, using what's already there - the configuration data has two parts (excuse me as I'm working from memory) app config and user config. The app config is basically defined when the app is pulled down however the user config is just that - you set up the defaults and then, once set by the application on behalf of the user, it won't be overwritten when the app is updated.
It should be straightforward enough to provide a configuration editor - something as simple as a two column grid would be sufficient with a read only label column and an editable value column (although you're going to be somewhat challenged on validation).
Alternatively, if you're happier with a more traditional configuration, then you need precisely 1 user value and that would be the location for the config file... if you don't know if (or can't find the file) prompt to create, dump your default config to the specified location from a resource within you app and then you've got your config file and away you go.
One project I worked on, we made the app download a configuration file from the server it was deployed from (this was done on each startup to cope with if app was added to the Start Menu and cached). The ClickOnce API gives you the server address.
On another project we just pass a few config values as query strings to the ClickOnce app, these were generated by the Asp.net page that had the link to the app.
This allowed customers to change the config for their site without having to resign etc.
(This does not help with per-user config)