Develop Reference

appSettings in Web.config and Web.Release.config

Trying to get simple <appSettings> for dev vs. prod.
My Web.config:
<appSettings>
<add key="hello" value="debug" />
</appSettings>
My Web.Release.config:
<appSettings>
<add key="hello" value="prod" />
</appSettings>
(both under <configuration>)
When I have it in Debug mode, and run my MVC site, I can do a simple return Content(WebConfigurationManager.AppSettings["hello"]); in my HomeController.Index and it returns dev. If I switch the mode to Release it still returns dev. I'd like to simulate prod mode without actually publishing to prod.

In the build-specific Web.config file, you have to tell it how to transform the base .config file. So to do what you ask, your Web.Release.config file should look like this:
<appSettings>
<add key="hello" value="prod" xdt:Transform="SetAttributes" xdt:Locator="Match(key)" />
</appSettings>
In the above code the SetAttributes transform will change the attributes of any element that matches the key attribute containing the value hello.

Starting from .NET 4.7.1 feature called Configuration builder is supported which gives developer ability to load configuration not only from Web.Release.Cong but basically from any source. Read more about .NET Framework 4.7.1 ASP.NET and Configuration features

Set different appSettings key in production server

How can I set a different value when I publish my MVC5 do production server?
Example:
In dev I have
<appSettings>
<add key="XLSFile" value="C:\\temp\\file.xls" />
</appSettings>
And when I publish the project I want to set a different path:
<appSettings>
<add key="XLSFile" value="C:\\projectname\\file.xls" />
</appSettings>

You'll want to use a config file transformation. Essentially you will override the config file for your release build.
For example:
<add key="XLSFile" value="C:\\projectname\\file.xls" xdt:Transform="Replace" xdt:Locator="Match(key)"/>

You can use two config files one with name web.Debug.config and second web.Release.config. First one for development and second for production server when published and now specify different value of key in both files as required

when does web.debug.config apply?

I have a project which has a normal web.config with the following appsettings:
<add key="CachingEnabled" value="true"/>
<add key="IsDeployed" value="true"/>
In my web.debug.config I have tried to overwrite these settings with
<add key="CachingEnabled" value="false" xdt:Transform="SetAttributes" xdt:Locator="Match(key)"/>
<add key="IsDeployed" value="false" xdt:Transform="SetAttributes" xdt:Locator="Match(key)"/>
And I also put the corresponding values in the web.release.config
However, when I step through my code, these values are still the same as the ones in the main web.config
Do these values only apply if you deploy the site in debug mode or should they work if you are just running the site locally? I am running the site locally through iis rather than by pressing the play button in visual studio if that makes any difference.

These values don't apply to anything, what happens is as part of the publish command VS transforms your default web.config using the rules you have defined in your build-specific web.config (in your case, your debug build config).
A lot of people get confused thinking that these values just automagically work when you build your project, that's not the case. However, if you want this behaviour there is a nice little plugin called SlowCheetah that will do this for you.
It's worth reading up on Web.config File Transformations and How to: Transform Web.config When Deploying a Web Application Project

The web.debug.config or web.release.config are only consumed by web deployment to transform web.config, say "Build deployment package" or "Publish". Regular build/debug doesn't invoke transform.
SlowCheetah may be able to help you: http://visualstudiogallery.msdn.microsoft.com/69023d00-a4f9-4a34-a6cd-7e854ba318b5

ConnectionString for assemblies

I have a website with a connection string listed in its web.config. The connection string is altered by the Publish feature so that it can reference a development database until it is released, when it references a separate release database.
The website accesses the databases through some assemblies, though. They are Class Libraries so they can't be Published, at least as far as I can tell. I read that the web.config would override the app.config connectionstrings, but that doesn't seem to be happening.
Whenever I Publish the release site references the development database, unless I alter the assemblies app.config files to reference the release database.
I don't want to have to remember to do that every time. How do I handle this?

You've got two issues here:
1. How to remember to publish the correct settings each time you publish:
One way to deploy such settings is by using web.config transformations in Visual Studio. This is pretty easy to set up and means that you do not have to remember to update the settings each time you publish.
As well as debug and release environments, you can also create transforms for "UAT", "Staging", "Beta" or whatever other configs you might need.
You might find these articles useful: here, here and here.
For example, here is a transform for a Release environment:
<?xml version="1.0"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
<connectionStrings>
<add name="MyDB"
connectionString="Data Source=ReleaseSQLServer;Initial Catalog=MyReleaseDB;Integrated Security=True"
xdt:Transform="SetAttributes" xdt:Locator="Match(name)"/>
</connectionStrings>
<system.web>
<compilation xdt:Transform="RemoveAttributes(debug)" />
<customErrors defaultRedirect="GenericError.htm"
mode="RemoteOnly" xdt:Transform="Replace">
<error statusCode="500" redirect="InternalError.htm"/>
</customErrors>
</system.web>
</configuration>
Above, you will see that the transform for Release mode sets the attributes of the MyDB connection string (xdt:Transform="SetAttributes"), removes the debug attribute from the compilation section and replaces the customErrors section with a new version.
It's a simple, yet very powerful technique.
2. How to get your assemblies to pick up the settings in the web.config
If your libraries have been written in the usual way, they should be retrieving their connection strings by simply accessing the [Web]ConfigurationManager.ConnectionStrings property. Like #Bob Horn says, they should then pick up the settings from the host process's config file (in this case the web.config of your web app).
However, sometimes you might find that a library is getting its settings from a .Settings file in the project, in which case things get a little more complicated. You will need to copy the settings section of the app.config in to the web.config. (You can also do this using the transforms technology described above.)
If you have access to the source code of the other assemblies, find the part of the code that retrieves connection strings. If it's not accessing the ConfigurationManager class, then that might explain why it's not picking up the web.config file.

How does web.config files works in C# works?

Let's say that in my main startup project I have web.config file with some setting:
<!-- ... -->
<appSettings>
<add key="Setting" value="setMe!" />
</appSettings>
<!-- ... -->
This project has two configurations: Release and Debug. Each transforms this setting to its own value, for example web.Debug.config:
<!-- ... -->
<appSettings xdt:Transform="Replace">
<add key="Setting" value="debugValue" />
</appSettings>
<!-- ... -->
When I compile it there is no transformed config file. I have only three files: web.config, web.Debug.config and web.Release.config.

You have to publish your project ("Publish Web Site" command) and your destination (IIS) will use the correct web.config file with your Release configuration.

Configuration transformation is only done when publishing. Your base configuration file should have your development settings. If you choose to use the default build configurations, normally the release transform file should contain your production environment settings and the debug transform file will contain your test environment settings.
Personally, I usually create a new build configuration for testing and for production and leave the debug and release transforms empty.