HTTP error 500.19 - Cannot read configuration file

Question

In one of my ASP.NET apps, all of a sudden I am unable to run it in Visual Studio 2013 due to the error displayed below. It appears that it is trying to open the web.config from a path that doesn't even exist. All of my project code, including web.config, are located under C:\Projects\SourceCode\AFEManager\Trunk\AFEManager.Web. I've found a number of posts here from users experiencing a similar error, but the solutions seem to vary and none I've found so far seem applicable to my situation. I looked in that TraceLogFiles directory and the most recent log file there is five days old so it obviously hasn't been logging anything since I've been having this issue. Any suggestions are appreciated.

Answer 1

In my case I deleted all folders in D:\My Documents\My Web Sites\ before Then I caught the error There is a file .vs\config\applicationhost.config in my solution folder It contains reference to the deleted folder. So, I deleted applicationhost.config and then pressed 'Create Virtual Directory' button in my project property Web page. It was recreated the file and the folder

Answer 2

I've been able to resolve this issue even though I can't say I fully understand all of the details. I'll attempt to describe the situation the best I understand it and hopefully others with greater insight can add further clarification.

After having been doing all of my development on my workstation, it was suggested that I begin doing this work in a new VM environment that had been set up for me. So I installed VS 2013 there and copied my source code from various projects over there. However, rather than follow my previous local path convention of C:\Projects\SourceCode[ProjectName]... this time I decided to use the directories that are set up during the VS install, c:\users[MyUser]\My Documents\Visual Studio 2013\Projects[ProjectName]. Sometime shortly thereafter, our infrastructure team made a change so that my home directory, c:\users\rmayer, was now being pointed to a common network drive, \totalsafety\TSUsers\rmayer. Everything continued to work without any issues.

However, due to various difficulties I had working in this VM environment, I decided to return to doing my development work on my workstation using the original local paths for my source code. This is when I began encountering the errors described above whenever I would try to run my code through VS. What I've begun to learn is that there is an applicationhost.config file that IIS Express uses located here: \totalsafety\TSUsers\rmayer\My Documents\IISExpress\config. It contains entries for each of my web projects; the one relevant to this issue had a section which looked like this:

        <site name="AFEManager.Web-Site" id="8">             <application path="/" applicationPool="Clr4IntegratedAppPool">                 <virtualDirectory path="/" physicalPath="C:\Users\rmayer\Documents\My Web Sites\AFEManager.Web-Site" />             </application>             <application path="/AFEManager" applicationPool="Clr4IntegratedAppPool">                 <virtualDirectory path="/" physicalPath="C:\Projects\SourceCode\AFEManager\Trunk\AFEManager.Web" />             </application>             <bindings>                 <binding protocol="http" bindingInformation="*:19257:localhost" />             </bindings>         </site> 

The physical path attribute listed under applicationPool="Clr4IntegratedAppPool" at that time was set based on the local path I had been using at the time I was working in the VM environment. Now that this one file is being shared regardless of whether I'm working locally or within the VM due to the move of the users' home directories, this path is invalid when I'm working from my workstation. By updating this path to C:\Projects\SourceCode\AFEManager\Trunk\AFEManager.Web, it now works correctly from my workstation.

Again, I have a limited understanding of how this is supposed to work, but what it's telling me is that I will be unable to do development work from multiple environments (not that I want to any longer) unless the local paths are consistent between all of them. If I'm correct about this, this seems like a less than ideal design.