Preparing for conferences is fun.  It forces me to put things together and take concepts that I’ve used in developing client applications and packaging them in ways that other people can use.  That’s why I’m happy to announce availability of the Provider Logging project on Codeplex.  The Provider Logging project is a set of providers for ASP.NET.  These providers encapsulate another provider so that you can monitor the interaction between ASP.NET and your provider – or one of the out of the box providers.

The Provider Logging project currently includes logging providers for Membership, Roles, and Site Map.  The intent is that logging providers for the other ASP.NET provider model options would be written too. (I’m calling for volunteers)  All of the logging providers do so by writing out via System.Diagnostics.Trace.  From there you can configure the trace logger based on one of the built in ASP.NET loggers.  There’s a sample ASP.NET web site included in the source code which has a web.config that is configured with the file logger.  Because they use System.Diagnostics.Trace you can choose where you log their output, and can even filter the output of them to get only the events that you’re interested in.

One might wonder why the Provider Logging project was necessary.  There are two key reasons why I felt like the Provider Logging project was necessary:

1. A training tool – There’s nothing like seeing how the interaction really works to help you build better providers.  The provider model and how the calls are made are documented but the normal sequences of events are not documented very well, so with the Provider Logging providers you can see the sequences that happen.
2. A diagnostic tool – ASP.NET isn’t the best about explaining why it took an action or didn’t take an action based on the response of the provider.  It blindly carries on.  However, if you’re not getting the behavior you want you are left guessing and without much hope of figuring out what’s going on.  This is particularly true in tools like Microsoft SharePoint that leverage ASP.NET.  (In fact, all of the providers in the initial release were written to debug problems with various providers as they were used in SharePoint.)

The Provider Logging project represents that core of the custom authentication presentations that I’m giving at the Office Developers Conference and SharePoint Connections.  We’ll be tearing apart what happens when authentication providers are called by the ASP.NET framework – and what happens when they’re called in SharePoint.  If you need to write a custom authentication provider and can’t wait for those presentations, check out the Provider Logging project.  It’s not a replacement for attending my custom authentication sessions, but it’s a step in the right direction.