I am fairly new to C# and I was wondering how to keep an XML file from being overwritten if one already exists on the install. In the application, there are two files that contain info to connect to the Database. One of them is relatively dynamic, but the other is saved at the setup. If I do a publish and try to update the application it always overwrites both files. Any thoughts?
You can check if the file exists with File.Exists(Path)
You can look here for more information:
https://learn.microsoft.com/en-us/dotnet/api/system.io.file.exists?view=netcore-3.1
If this does not work you can try to read that file and if there is any data there just sont delete it.
I assume you are refering to configuration settings.
While designing your settings, in the designer, set scope to "User". This will bind the setting to the users local app settings, and will not be overwritten.
More info here: https://learn.microsoft.com/en-us/dotnet/framework/winforms/advanced/how-to-create-a-new-setting-at-design-time
Related
I am currently developing a ClickOnce application that converts CSV files for a database update. The program requires the user to have the ability to change the configuration files for a database change, and change an XML file which populates a drop-down list in the app.
Now I understand that the files are kept in the user/appdata folder to ensure there have the correct privileges, but do I have any influence as to what those folders are called, or where they are saved?
By default, the files are saved in AppData\Local\Apps\2.0\LD7ZEJK0.7AE\NJ42PEPW.1QX\csvt...exe_169e1a4011fbe7ec_0001.0000_none_04507fe9e077ae84
Can I change that to say Documents\CSV_Files or something similar? And if I do, how would I reference the XML file in the configuration file so the program knows where it is?
Normally, you shouldn't have to care about the location yourself. Just mark your XML file as data in the ClickOnce manifest and access it using the well-known:
ApplicationDeployment.CurrentDeployment.DataDirectory
Here's an MSDN article describing it: Accessing Local and Remote Data in ClickOnce Applications
I would never store any data that is important to be retained in the case of an update in the actual ClickOnce deployment directories -- it is too dangerous. You should copy those files out to ApplicationData and access them there. This article shows you how to do that.
I have a C# app which reads from and writes to an Access database. There is one database file per user. My intention is to check for the existence of the MDB in the user's My Documents folder at launch, and if the MDB isn't found, then copy the template MDB to that folder.
I have already added the template MDB to my project and placed it in its own folder which I have called Packaged. However, I am unable to refer to this Packaged folder from code as it doesn't appear in IntelliSense.
My intention had been to use File.Copy to copy the MDB over, but I cannot determine the file path as I can't access the MDB in code. And presumably it wouldn't have a file path anyway if it's just packaged in the .exe?
What would be the best way to achieve this, given that I would rather not distribute a separate MDB if possible?
I've done this in the past by making the MDB an embedded resource, and writing it to disk as needed (if it doesn't exist).
Here is more info on writing an embedded resource to file.
You'd almost have to use one of the Environmental paths for the template MDB. Like ApplicationData or Documents and Settings\Username\Local Settings\ or one of the other ones. Local User Data is the best way for user specific data. IN the code in the beginning, determine to see if the file exists in the first run. If it exists copy the template, if not don't.
That way the user has full read and write access and the ability to copy the file or duplicate the file without security problems. These environmental variables are accessible through
Environment.GetEnvironmentVariable
You could also have a registry setting and read and write to the registry for that specific application, that has a simple DatabaseAvailable key, and toggle it yes or no.
You could also embed the MDB as a resource too, and then write it as necessary.
I have a database that I connect as a file, i.e. through the AttachDBFile attribute in ConnectionString in web.config file of ASP.NET site. The database is in the App_Data folder od the website. I made a small app, that should allow to copy paste (a kind of backup functionality) the database to any chosen directory. For this I am using FileDialog box for allowing the user to chose the destination directory. I am using the .NET FileSystem API for copy pasting. The problem is that, I cannot copy paste the database till I shut down the SQL Express service. During copy, a dialog saying that the file is currently under use by other process is shown. If I turn off the service I can copy paste the database.
I used AttachDBFile attribute, since I thought that it will allow such copy, since this doesnt directly attach the database to the server. But now I think its not like that. :(
So how I can deal with this. Please help. Thank you.
You get the error since the file is locked while it's in use.
Have a look at the recommended ways to backup your database at msdn: http://msdn.microsoft.com/en-us/library/ms187510.aspx.
We are working with two different teams on the same project. In a configuration file App.config, we have two connections string with our connection settings to connect to our database and the second team has another database with a different connection string. I have to comment the second connection string and uncomment the first. I have to check always this file if the connection string is correct (if the another team has not commited this file). It's a little bit boring..
This configuration file contains some other configurations keys that we use in common. My goal is to set (on the config file with a or somewhat) to tell to SVN to not include this part of file when I made a commit.
Is it possible ?
Partial file commits aren't possible in any version tracking system I've ever seen. You can however take a look at something like this if you're using VS2010.
You can use the configSource attribute to have ASP.NET read the config from an external file instead of the main config file. That way you can have one dirty and ignore-on-commit file containing the connection strings, and still be able to commit the main config file when changes are needed.
I suggest that everyone in your teams backup the configuration file, and have someone rename the file in SVN to something like template.[original-name] and commit that.
Then, have everybody restore their own configuration file and put in into the svn:ignore Subversion property of the directory containing the file, and commit that directory to have the svn:ignore in version control for everyone and have them update their working copies after that.
This way, each team member can have a different configuration.
Configuration and user/system specific files should not be in version control.
See also http://svnbook.red-bean.com/nightly/en/svn.advanced.props.special.ignore.html.
EDIT: To actually answer your question, David is right, partial file commits are not possible (and usually would not make sense either). It is not the intended workflow of Subversion.
I know it is a good idea to store configuration data in app.config (e.g. database connection strings) instead of hardcoing it, even if I am writing an application just for myself. But is there a way to update the configuration data stored in app.config from the program that is using it?
If you use the Settings for the project, you can mark each setting as either application or user.
If they're set as user, they will be stored per-user and when you call the Save method it will be updated in the config for that user.
Code project has a really detailed article on saving all types of settings.
app.config isn't what you want to use for user-tweakable data, as it'll be stored somewhere in Program Files (which the user shouldn't have write permissions to). Instead, settings marked with a UserScopedSettingAttribute will end up in a user-scoped .config file somewhere in %LocalAppData%.
I found the best way to learn this stuff was to mess with the Visual Studio "Settings" tab (on your project's property pages), then look at the code that it generates and look in %LocalAppData% to see the file that it generates.