I’ve received some questions recently regarding ELMAH.MVC nuget package. Here is the summary blog post and I hope it is helpful.
Indeed, the demo project on a github uses simple
Elmah.MemoryErrorLog just holding all errors in session. That works great for small application or just to try out things. In reallity you need some persistant storage, like files or database. And this is extreamly easy to do. Take a look at this section of web.config:
<elmah> <security allowRemoteAccess="yes" /> <errorLog type="Elmah.MemoryErrorLog, Elmah"/> <!--<errorLog type="Elmah.SqlErrorLog, Elmah" connectionStringName="elmah" />--> <!--<errorLog type="Elmah.XmlFileErrorLog, Elmah" logPath="~/App_Data/Elmah.Errors" />--> </elmah>
Just comment out
Elmah.MemoryErrorLog and de-comment
Elmah.SqlErrorLog (will store errors to SQL database) or
Elmah.XmlFileErrorLog (will store errors to XML files). XML logger, just requires a virtual path to folder there files will be stored. Sql logger, requires a connection string name for ELMAH database. The same web.config contains:
<connectionStrings> <add name="elmah" connectionString="Data Source=.\SQLEXPRESS;Initial Catalog=elmah;Integrated Security=True" providerName="System.Data.SqlClient" /> </connectionStrings>
The database have to have ELMAH schema inside. It is very easy to prepare that schema, just run this SQL script against database you want to keep errors to.
This is a misconception. ELMAH.MVC is not about custom pages, at all. This is good answer on stackoverflow on that. For a code example, you can refer to something I did for before my projects just here
I’ve received that kind report on github issues. Initially I thought to do something about it but then I left that idea. The explanation is inside the ticket.
Short answer is, ELMAH.MVC is nothing more that boilerplate code. As soon as you can see it work and it works OK for you, adopt it for your custom needs. That’s it.