We Keep Coding

Does .NET have a built-in way to handle Config Management, other than Properties.Settings?

I've run into some issues with the Visual Studio Properties.Settings.Default method of saving config values persistently in a user.config file in AppData. The main problem is the way the file is stored - it's location (and the file contents) when running unit tests compared to the main executable. It also changes along with the assembly version.
Update:
To clarify (per comments), when running the app different ways (and from different projects in a solution), the Properties.Settings.Default auto-generated functionality uses a different folder to store the user.config file in each case:
When running the application directly (with the company name in the assembly information empty):
[Documents]\AppData\[MyApp]\[MyApp.Exe]_Url_[hash]\1.0.0.0\user.config
When running the Resharper test runner:
[Documents]\AppData\JetBrains\[MyUnitTestProjectName]_StrongName_[hash]\109.0.0.0\user.config
When running the xunit test runner within Visual Studio:
[Documents]\AppData\Microsoft_Corporation\[MyUnitTestProjectName]_StrongName_[hash]\15.0.26720.2\user.config
Since the user.config file is stored and looked for in different places, depending on whether I'm running the app directly or running unit tests, when I save info out of my normal running exe, I cannot access that same info while running unit tests.
Similarly, if I switch from a GUI frontend to a Console frontend, I have the same issue, because the file is specific to the run-time executable parent (I think). I just want a single config that is saved and used for any part of a given solution that wants to access it.
So, is there another built-in way to do configuration management in .NET, or another way to solve this issue?
I see lots of applications that have custom named config files and other data in their AppData folders - are they using a standard .NET library for that?

C# Console application keeps creating a Configuration FIle

I am new to C#. I am an admin, not a programmer, but I am starting to see how being able to write some console apps could help me with automation. So I wrote one and it works well.
Here is the issue. Every time I execute the exe file for the console application, it generates a .config file. There isn't really anything in the config file. just a few lines. How do I make it stop. The Program.cs is really just calling SCOM's SDK to put a machine into maintenance mode.
Developed in: c# in visual studio 2013
.net version used - 3.5

It's not entirely clear what you're asking. But assuming commenter Jon's guess is correct, and that you really mean that when you build your executable, a .config file is generated, then his advice is correct: just remove the "App.config" file from your project, and no .config file will be generated. The "App.config" file is the template for the .config file; at build time, the file is copied to the output directly, using the executable name and the extension .config.
Please note that this may or may not be safe to do. It probably is. However, some C# projects have configuration information in the .config file that is actually needed. Please see Is app.config required in .Net 4.0 C# projects? for more details on that question.
Finally, I will suggest that for simple automation tasks, you may find other tools more appropriate that even a simple C# console program. The two I use most commonly are PowerShell and plain old batch files, though there are a number of other similar scripting-style automation tools that work on Windows (including a variety of *nix-style shells that are compiled for Windows).

Where are my application settings stored exactly?

With a Windows Forms (or WPF) application, if I create an installer through Publish command (ClickOnce that is), the installer creates application folder with executable and config file in C:\Users\[UserName]\AppData\. On the other hand, if the installer is created through Setup project (MSI), the installed app would be in C:\Program Files\My Company\My App with both the executable and the config file. Out of the two, I chose MSI path.
My expectation was that the application settings (as in Project properties > Settings tab) are read from/written to the config file that is in Program Files, which remains there even if I uninstall the program or upgrade it with a newer version, so that user's settings don't get lost. But it doesn't appear to be the case. Even that the Program Files version of the config file is there, the installed application appears to be reading from/writing to C:\Users\[UserName]\AppData\ as if it were a ClickOnce app. What am I missing?
(This is VS2010 + Win7 + C# + .NET 4.0 Client Profile, though I don't think those things have anything to do).

I hope I understand your question in the right way.
If you want to know, why settings are read from/written to the AppData folder, then it's because of security/permission reasons.
When first starting your application, your initially application settings from app.config file were copied to that folder. Your application will automatically work on that newly created file.
This is done, because it's a risk letting the user work on the "global" settings in your Program Files folder, with which all your users will work. Think about what would happen, if a user only has permissions to read, but not to write to this file.

Release Windows Forms project without an installer

I've built against the release profile and this creates an executable build within the release directory in my project.
How do I best distribute to clients from this executable? There are a lot of files within this folder which don't appear when installed through the installer, such as the mainifest and one called application.exe.xml (which is confusing when Windows hides the extension in Windows Explorer).
Are these all necessary? Can I just send the executable? Or will I need to send with all the files? Is there a way to build without all these files?

You must send the EXE file and any DLL file that you reference locally. If you use COM references and the like, you need to register them during the installation. The same thing for the GAC I think, but I haven't used that for stand-alone applications myself.
The application.exe.config file contains the application settings (a copy of app.config). If you don't use settings or the user doesn't typically care about them, you can omit the file, and it will use the default values you built the application with.
The vshost files are not needed (if you have them). They are used by Visual Studio's debugger. The .pdb files contain debug data used to facilitate DLL file to source matching. Unless you plan on attaching a debugger to the application, there is no point sending those.

Usually, in an XCopy deployment you have to deploy (literally copy all files deployment with no setup/installer program) the content of the output folder (like debug or release) without:
*.pdb - debug symbols
*.xml - xml documentation
?vshost? - Visual Studio hosting files
In fact, it anyway also depends on your specific application. As a developer, you need to know what you are producing; in case you are using an xml file which is not the result of the .NET documentation compiler, but a static file copied in the output folder, then do not forget to deploy it.
A last note: developers usually disable the option to hide file extensions in Windows Explorer ;-)

You need to understand what an installer does or why an installer is important.
An installer takes care of the basic environment. The installer can carry dependent assemblies/modules along with the application. It can also check if you need something before you run, like .NET on the target machine. It can also create the shortcuts on the desktop or start menu. Plus it also provides adequate options on the target machine to uninstall it.
If you wish to ship the executable alone, you might miss out some assemblies that the executable depends on. The target machine may or may not have the correct .NET version installed.

Use the program: HM NIS EDIT from HM Soft.
Build your project
Run NIS EDIT
Make a new script from the wizard (Ctrl + W)
Run all the steps
Select all the .dll and .exe files
Build a setup file

Updates made to application config are only being read correctly in Windows 7 when the application runs as Administrator

We have an application that was built for the Windows Mobile and Windows platforms, using Visual Studio 2005. We have both versions of this application developed using a single code base to try and reduce code duplication. One of the issues that we encountered with this was that the ConfigurationManager was not available for the Windows Mobile platform. We worked around this by building our own ConfigurationManager that reads and writes settings to the "Application.exe.config" file in the Program Files folder. So both our Windows version and our Windows Mobile version use this same custom ConfigurationManager.
This worked fine on Windows XP and Windows Server 2003, but on Windows 7 we have encountered a problem and I don't know how to work around it. When we make a change to the config file (which we can only do by copying it to another folder, changing it and then copying it back... otherwise we get an "access denied" message when we try to save our changes directly in the Program Files folder), the change that we make is only reflected if we run the application as Administrator. If we run the application as a normal user, the default setting from the install are always shown. We suspect that this is a Windows 7 security-related issue, but can someone explain why this is happening? How can we change the settings so that they are also applied when the application is run as an ordinary user?

Windows 7 requires elevated privileges for several folders, including program files. It's not good practice to try to work around this.
Since you are using a custom solution, one option is placing your configuration file under %APPDATA%\yourproduct, which can be reached with
var appDataFolder = Path.Combine(Environment.SpecialFolder.ApplicationData, product);
A better solution is probably to use different configuration managers for different platforms, though. Couldn't some kind of abstract factory be applied?

I suspect your app tried to write to the config file at least once running non elevated and without a manifest. This made a "compatibility files" folder for your config file. When you run non elevated it looks there now. (See http://www.gregcons.com/KateBlog/FindingFilesYoureSureYouWrote.aspx for screenshots of how you can confirm this.)
If all you want is for a human, or some utility program you wrote that can run elevated, to be able to edit the config file, you can leave it where it is and put a manifest on your app to prevent virtualization. See http://www.gregcons.com/KateBlog/AddingAManifestToAVistaApplication.aspx for a sample manifest. That blog post goes on to tell you how to embed the manifest, but you don't need to, an external manifest will work. If your app is foo.exe, name the manifest foo.exe.manifest and put it in the same folder. This will prevent virtualization and cause the app to read the "real" config file.
If changing the config file will be a normal everyday occurrence, don't write the file under Program Files. AppData is a good choice.