Advanced web.config transformations

Nov 13, 2010 at 2:21 PM

Hi there,

I'm one of the developers on the ELMAH project and am looking into how I can improve the NuGet experience for ELMAH users.

The problem with the existing package is that it only does part of the configuration that a user will need, and there are lots of options that the user might and probably will want to choose. For example:

  • Where are errors logged?:
    • In memory
    • XML files
    • Sql Server
    • Oracle
    • SQLite
    • MS Access
  • Which connection string to use when logging errors?
  • Are errors emailed to users?
  • Are errors tweeted to users?
  • Are errors filtered, and if so using what criteria?
  • Can the error log be viewed by remote users?

And then if the user wants to log errors to Sql Server or Oracle, they will need to find and run a SQL script against their database - and then re-run this against a different database when they deploy to production.

I guess I could simply update things such that common options are set up and other options are commented out with instructions as to what should be done. However, that still leaves a lot for users to do.

Another option might be that there is an Elmah.Core package that sets up in memory logging, then Elmah.SqlServer that transforms the web.config to log to SqlServer, then Elmah.Mail and Elmah.Tweet etc. Each of the NuGet packages would do a little bit of the transformation and allow users to selectively pick the features they want.

Does anyone have any ideas of the best way to solve some of these problems/give users the best possible experience??



Nov 14, 2010 at 6:45 AM
Edited Nov 14, 2010 at 6:45 AM

Hi James,

Yes, I like the option of creating separate packages that enable different types of scenarios.  Each specialized package would of course have a dependency on core Elmah.

It would be great if an Elmah expert like you could take ownership of those packages to make sure they're well taken care of :)


Nov 14, 2010 at 11:16 AM

Hi David,

I plan to take over the ELMAH package fairly soon once I've fully gotten to grips with the way things will work.

I will investigate the multiple packages route and see what I come up with. I'm thinking that an Elmah.All or Elmah.CommonConfiguration might be useful too.

Any ideas about the connection strings?? Or maybe I just add in a sample connection string with a name of "elmah".




Nov 14, 2010 at 3:32 PM
You should make one that uses SqlCE and EF code first. Then, you could inject a connection string pointing to the SqlCE database. Then to switch to SQL server, a user can just change the connection string to point to another database. No need for different packages for different databases!

I think that would make a good default elmah package as it would be bin deployable.

Nov 14, 2010 at 10:17 PM

Yes, that would indeed be cool if ELMAH logging over EF/SQLCE can be setup in a simple package install!

Nov 21, 2010 at 9:54 AM
Edited Nov 21, 2010 at 9:54 AM

I have a Elmah patch ready, that allows loggin to a SQL Server Compact 4.0 database:

Please let me know if I can assist with this in other ways.


Nov 21, 2010 at 9:15 PM

Is that the ErikEJ.SqlCeMembership package you just submitted? Wait, no, that  looks unrelated :)