My application connects to different databases. The connection strings are saved in the user settings. I cannot use the application scope because the data is changed at run-time.
If the user starts the application normally there is no problem. However, if he uses the "Run..." command from the Start menu then a different folder in User\AppData\Local\MyApplication is created containing a different user.config.
Is there any way to stop or bypass this behavior?
This behavior cannot be avoided.
It seems that Windows does not identify programs started by other programs as the same as programs which are run by the user.
To solve the problem you have to avoid settings made by the ConfigurationManager and create your own files to save data as pointed out in the comments.
Related
I would like your opinion.
I am creating a WinForm application (C#) and I would like to know if there is any problem using a local database to save the application settings instead of app.config. My system constantly retrieves configuration data to continue processes, but there are not many requests or require data with great information, just to validate whether one configuration or another is activated.
I already use mdf file to generate some filters, I was wondering if there is a problem putting the application settings in it.
My mdf file is 8mb in size, practically the standard when it is created, and will not store much information in it.
I have a webpage that offers an installer which adds an registry into user's computer based on the clients that the user has access to.
The installer is quite simple. It reads from its app.config, gets the client key and downloads configuration file that is used to create the registry.
Here is the thing, I use ClickOnce to deploy the app. The main logic of the installer remains the same, the only different thing is the app.config key. If the user has 5 clients, I have to publish 5 times since I separate different installers by setting different publish/install urls like below. BTW, I will have to define different Assembly Name too:
It's definitely not a good solution.
Is there any better ways that I can configure the installer to accept this parameter from the webpage, or other better ways to automate this process and then reduce the publish times?
Looking forward to any suggestions!
Thanks!
What I finally done is to write a powershell script, modify related parameters in csproj and deploy them. But I failed to copy those deployed files to remote server(aws). If anyone has any experience on that, you're more than welcome to share your thoughts!
Is it possible to create a C#.net (or a .bat) program that will automatically run upon access of a specific folder?
Thanks.
Windows 7/8/10: Not if you don't have a background process running that checks for the folder to be opened. So no, considering you want this to behave autonomously, I'm afraid not.
Windows XP: Yes, but let's not do that. This brings security issues and the only implementation I know of is the MS32DLL virus that would do this to partition roots.
EDIT: Based on your last comment (in particular the one that elaborates the context being data security), this is the wrong approach. There are multiple ways around this (think of any third party file browser, even DOS will work) and having this feature in Windows would leave it very vulnerable to attacks. Instead, you should read into applying NTFS permissions and file encryption.
In my applications there are some setting saved in the Properties.Settings.Default. These settings can be changed by the user(s) and needs to be saved locally on the computer. While I can save these setting, the problem is that it is only saved for the user currently logged in. Once an user changes a setting it has to be for all users of the computer. How can I accomplish this?
User scoped settings are just that, settings that an individual user can change and will only be saved for that user.
The application scoped settings will affect all users but they are not designed to be changed by a user.
You might want to consider a different approach to storing settings that you want users to be able to change but to affect all users of an application e.g. the Windows registry or an external xml file.
Another option is to use user scoped settings but to change the location to a centralised location so that all users use/save the same settings. See Store user settings into application folder for an option on how to do this.
When you open the Settings Designer window in Visual Studio, you have four values that you need to enter for each setting:
You need to set the Scope property to Application to have a setting that is the same for all users. For the full story, read the Using Application Settings and User Settings page on MSDN.
Application settings cannot be changed, only by hand before the application is run so I do not recommend that approach.
In my opinion, propagating the changes may be generally a bad approach. Since this config (user.config) is generally stored in the user's own folder (under Users), it should not be modified by another user (in fact, without administrator acces, another user cannot even access).
I might recommend using other places to store application specific settings: xml or config file near your application, or maybe the registry.
I would use an external Database for that Stuff...
But if you want it quick and simple just save it to a File on the Harddrive (for example C:\Program_Data\\settings.csv) i would use a csv file because it's not much work...
I want to know what is the actual difference between Application and User scope in Settings configuration for vs projects.
Is the only difference the fact that if I select Application, I can't use Settings.MyProperty as a setter, but I have to use Settings["MyProperty"] instead?
How would using the User scope affect the program otherwise, if the config file is located at my application root?
User scope means each user gets their own copy, the settings are stored in the users profile folders and your App can Save those settings without Admin privileges.
If you change an Application setting (using Settings["MyProperty"]) and call Settings.Save() you will have to be running as Admin because the changes are saved to MyApplication.exe.config . And changes apply to all users.
Your best bet is to use the 'User' setting because with the newer operating systems Windows doesn't like you reading and writing to files that are local to your executable, this looks suspicious due to the awareness of viruses. So Windows likes you to read and write to designated safe areas which I believe happens in some application data area that the operating system keeps track of. If you set the scope to 'Application' it may try to write this data to the local config file(which is why you need to run with admin privileges) and with the operating systems becoming more locked down there may still be issues doing this. Your app may work in XP like this but anything newer might not work, especially when apps run in the 'c:\Program Files' folders...