There is no problem with your web.config. Your web site runs under a process. In iis you can define the identity of that process. The identity that your web site's application pool runs as (Network Services, Local System, etc.), should have permission to access and read web.config file.
Update:
This updated answer is same as above, but a little longer and simpler and improved.
First of all: you don't have to change anything in your config file. It's OK. The problem is with windows file permissions.
This problems occurs because your application can not access and read web.config file.
Make the file accessible to IIS_IUSRS group. Just right click web.config and click properties, under security tab, add IIS_IUSRS.
So what is this IIS_IUSRS thing?
Your web site is like an exe file. Just like any exe file, it should be started by a user and it runs according to permissions assigned to that user.
When your site is started in IIS, Application Pool of your web site is associated with a user (Network Services, Local System, Etc. ...) (and can be changed in IIS)
So when you say IIS_IUSRS, it means any user (Network Services, Local System, Etc. ...) that your site is running as.
And as @Seph mentioned in comment below: If your computer is on a domain, remember that IIS_IUSRS group is a local group.
Also make sure that when you're trying to find this user check the location it should be set to local computer and not a corporate domain.
AppDomain.CurrentDomain.BaseDirectory
is probably the most useful for accessing files whose location is relative to the application install directory.
In an ASP.NET application, this will be the application root directory, not the bin subfolder - which is probably what you usually want. In a client application, it will be the directory containing the main executable.
In a VSTO 2005 application, it will be the directory containing the VSTO managed assemblies for your application, not, say, the path to the Excel executable.
The others may return different directories depending on your environment - for example see @Vimvq1987's answer.
CodeBase
is the place where a file was found and can be a URL beginning with http://. In which case Location
will probably be the assembly download cache. CodeBase is not guaranteed to be set for assemblies in the GAC.
UPDATE
These days (.NET Core, .NET Standard 1.3+ or .NET Framework 4.6+) it's better to use AppContext.BaseDirectory
rather than AppDomain.CurrentDomain.BaseDirectory
. Both are equivalent, but multiple AppDomains are no longer supported.
Best Solution
So the answer is two fold. First off a sub folder was being created before the permissions were set on the folder and I needed to or in one more flag on the permissions to make it so both folders and files inherited the permissions.
After that every thing appears to be working.