Apologies if this has already been answered on this site, I searched but did not find this exact scenario.
I'm adding log4net to a WCF service. I added a handler in the Application_Error event, and it is catching a file not found error on every request.
I've seen this with web sites, and usually the error can be traced down to not having a "favicon" file in the root directory, or to a missing image referenced in a css stylesheet.
However, this is a WCF service, there is no CSS stylesheet, and adding a favicon to the root did not solve the problem.
Does anyone else have a good way to troubleshoot this?
Some clues:
- I haven't deployed this yet to the real IIS server, I'm running it locally.
- The error does not happen when I am running in DEBUG inside Visual Studio, only when I access the service from a web browser (IE or Chrome)
I added the url and file path to the error message, and this is what they are:
FilePath: /
Error: System.Web.HttpException (0x80004005): File does not exist.
Edit: the above values are what show up in the logged exception:
protected void Application_Error(object sender, EventArgs e)
{
var objErr = Server.GetLastError().GetBaseException();
if (objErr is System.Web.HttpException)
{
var filePath = Context.Request.FilePath;
var url = ((HttpApplication) sender).Context.Request.Url;
Log.Error("URL: " + url + "; FilePath: " + filePath, objErr);
} else
Log.Error("Application Error", objErr);
}
Any help would be greatly appreciated.
The reason is likely that the service has not been specified. When a web server (the local dev one as well) recieve a request for a folder they look inside that folder for the default page (usually called: index.htm, index.html, default.asp, default.aspx, etc) and present that (unless you are using a REST based service description). When you run from VS the debug will take you straight to the actual service.
In this case because you have built a service you need to specify the location of the exact service i.e.
http://localhost:3994/service.svc
.Also: If you start a debug session and then change the URL to
http://localhost:3994/
you should be able to check this is the case with the debugger.