Do you mean from the following blog entry?
If so then it seems to me that it does the job though I would change the call to ErrorSignal.Raise to also send the HTTP context for more thorough logging. I did a quick test with the setup you described and I have shared my steps in the following repo & branch:
You can clone just the branch using:
git clone -b thread/6baNilOnWyk --single-branch https://github.com/elmah/discuss.git
In
960322f, I started with an
ASP.NET MVC web application created from the template in VS 2017. I targeted .NET Framework 4.6.2 instead of 4.7 because I don't have the latter and the former was the highest version on my machine.
In
a561083, I added ELMAH via ELMAH Bootstrapper and in
6f08d86 I added the
App_Data\errors\xmlstore directory so ELMAH Bootstrapper would use the
XmlFileErrorLog.
In
4788da0, I added the
error action from your initial post. At this point, all error logging was working as expected. When I did the custom error pages setup in
d219af4, the error action stopped logging. All other errors, that didn't go via the
ASP.NET MVC route, were still getting logged, like a 404 or the logging test built-into ELMAH. In
d602ea4, I added an improved version of Ivan's
ElmahHandledErrorLoggerFilter and the exception thrown by the error action was logging again. The improvement I made basically passes the HTTP context to ErrorSignal.Raise in addition to the exception to be logged.There is no better way to do it with ELMAH Bootstrapper as it has not dependency on
ASP.NET MVC.
Hope this helps.
- Atif