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.
Related
I'm trying to create software that will add a computer to an Active Directory domain. One criteria I need to meet is the machine must be added to the proper OU. In order to do this I have a set list of site locations with addresses (this is how we determine OU). This list is currently in the form of an ACCDB file, and I want to include this within the application as the Access list will not be changed.
Everything I see wants the DB file to be connected to in a different location such as server or on the local machine. My preference is to use the DB file as a reference or something inside the program's .exe file itself. I may be missing something horribly obvious, but it's been messing with me for a couple days so I'm reaching out for help.
To clarify, this software MUST be self contained (no installer). It must also be able to determine the proper OU to join to the domain (no access to shares until the PC joins the domain). It must also be user-friendly enough to avoid mistakes, meaning I want to avoid copying distributing multiple files that must go to a correct location. This is why I want to embed the ACCDB file into the application for on the fly use.
Things get much easier because this is static data. You don't have to worry about persisting this data, reclaiming changes into your program, or users accidentally deleting something, etc. You will be able to just use an embedded resource in your application. In the link, follow the examples using the image file. Text file examples will corrupt your database.
However, there is still a trick to doing this. The problem is the Access engine included with Windows will not be able to open the database as a resource, and so you will need to save this file to the local hard drive. The good news is its not as bad as it seems, because your program can do this as needed, and make sure it's right, rather than asking the user to put a file in a specific place.
As for where to put the file when you extract it... the safest and best place is the Application Data folder. You can easily get the path for this folder by checking the results of this call:
Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)
This will give you a path where standard privilege users do have write access, no matter which user.
In summary:
Embed the ACCDB as a resource.
When your program runs, get the Application Data path using the Environment object.
Open a FileStream for writing to a file based on the path from #2
Open the embedded resource as a Stream object in C#
Copy the stream from #4 to the stream from #3. Make sure to use a mechanism intended for binary data, rather than text.
Close/Dispose your streams, so no locks remain on the file. This is as simple as putting using blocks in the right places.
Open a normal Access connection to the file you just made, using any of the thousands of tutorials or examples available on the web as a guide.
In this way, you only need to distribute the final .exe file, and users won't need any special permissions to use the database. You don't have to worry if a user deletes your file; it's still embedded in the application, which will recreate it if needed every time it starts up.
The downside is a clever user may be able to manipulate the database to end up in an undesirable OU. If you need to worry about this, you should consider having the program check a web service, rather than using embedded data. Anything you embed can ultimately be altered by an end user. A web service is also nice because you can update your mapping data as your organization evolves, without needing to rebuild or redistribute the program.
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 have a WPF application, when the app runs I need to store a variable in a shared memory.
When the app is being closed and successively restart I need to get the variable previously stored. I need a simple solution, I would avoid using a text file saved in some place.
If the machine is restarted I do now need to get that variable.
Any idea what are my option?
You could use your Settings file to save properties between application sessions.
For more information see this and note the Saving User Settings at Run Time section. It technically is "saved" to a file, but in a much dev-friendly manner.
Edit: That is a link for VS2005, oops! Use ConfigurationManager.AppSettings and refer to this post when saving for newer apps.
If you're wanting to avoid writing/reading files, you could use the Registry.
I'm writing an application using windows form and c# 3.0. I was wondering if there is a recommended way of persist data across time. However, i do not want to touch the machine it is running on, as a result, i would like to store the data in the binary executable (preferably, due to the need not clutter up the user's folder with random config files).
So if anyone have any ideas of how to do this, it would be much appreciated!
Jason
If you're looking to store configuration information - app.config or a settings file is probably the way to go.
If you are storing user data - you should really allow the user to control where it is saved - and prefer the \User\Username folder on the machine.
As for what format to store it in ... you can certainly use something like SQLLite - but there's nothing wrong with XML either, if you're not storing true binary data. .NET offers a number of APIs to transform object graphs into XML representations - which you may want to look into.
If you don't want to store anything on the local user's machine, you probably want a network database - or a webservice - to which you upload the users data. Just make sure your users understand this - many don't like their private data being sent somewhere on the web without their consent.
You really don't want to go about modifying the executable file. Many virus scanners quarantine executables that are constantly changing in content or size - as a way to proactively prevent viruses and malware from infecting the machine. You don't want to go there.
Do not modify the executable. Adding a single SQLite database is a much better solution.
Isolated storage is another alternative.
Doesn't clutter install directory
Doesn't cause issues with AnitVirus software
Part of the OS including .Net objects, don't need to install anything else
Already works with the Windows security model
Exists on a per user basis, so saved settings are separated for each user
Can serialize/deserialize obects directly into it
SQLite is what your looking for and is compatible with c#
If you dont want to store data in a SQLite db on the end users PC you could call out to a web service on another server which stores it's data in SQL Server or something else.
I don't believe a windows form project can modify itself like that (I've tried to find a way to do this myself some time ago). Some form of hosted application such as a silverlight application (where the application is essentially a zip file) may be the way to go. Silverlight applications would require the silverlight plugin though (and I'm still not sure if a silverlight application is allowed to modify itself).
I would think that one config file of some sort would be prefereable, and not leave much clutter.
One way to ensure that your applicaiton is entirely self contained would be to use a program like ThinStall after you have compiled the project. This virtualises the application and could give it it's own file system or registry internally to the .exe file.
One way for an executable to change itself would be to put another executable inside it, (embed as a resource then extract it to a file when needed). This executable could then modify the first, however I don't think ther'es any framework for it to do that, so it would require knowing excatly what to change and where.
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)