We Keep Coding

Not overwriting saved xml files in C# Window Form

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

Permanently add a database to an application C#

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.

C#: restore SQL Server DB from a backup inside an embedded resource

I have a file that contains a SQL Server 2012 database backup. I am using this file with a C# WinForms application, that creates a database, restores the backup into it, and then performs some more functions.
I don't want to just add this backup file to my application, because this is a security issue. I was thinking I should add the backup as an embedded resource, and then save it to a temp file, restore from it and delete it.
Is there a better way to do this? Is there a way to access an embedded resource directly through a file path that I can pass to SQL server to use in the RESTORE DATABASE command?

SQL Server has no idea whatsoever about how to restore a database from something living inside an executable. Given that you state that you've considered it be able to be an embedded resource, I am going to assume that it's not a "last known good" backup, but more a "default" backup.
If I am correct in this thinking, then you're basically saying you have a default set-up. If that is the case, you don't need a backup at all, your code just needs to be able to create a database and populate it with certain things to "become" that default state. By embedding a backup as a resource, you are (in my mind) stating that the structure and data is well known, so why go down the RESTORE DATABASE path at all?

ClickOnce Application user settings locations

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.

Distributing an Access database with a Winforms app

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.