released! I downloaded, installed and got to evaluating it today.
I'm focusing on the Exception Handling Application Block as it is the most immediate fit for my organization. I was using the EMAB on one previous project but never made it a core architectural component. This time its a keeper!
Setting up
The best way to get a handle on things is using the quick starts. Install the Application Blocks, choose Start Menu\Programs\Microsoft patterns & practices\Enterprise Library - January 2006\QuickStart Applications\Exception Handling Application Block\C# Exception Handling With Logging QuickStart.
Set a break point in the button click, F5, go>>>
You should get a basic feel for the implementation pattern.
I followed the simple instructions, configured my web.config using the configuration tool (Start Menu\Programs\Microsoft patterns & practices\Enterprise Library - January 2006\Enterprise Library Configuration) but when I launched, I got an error.
By the way, when configuring web.config, don't select "New Application", use "Open Application" and browse to your web.config. I made that mistake three times before I figured it out.
The error was basically telling me it couldn't create the logger. I've seen that often enough in my own provider patterns to recognize it in a minute. I still managed to sprint down the worng apth, thinking it was because I hadn't signed my assemblies, and started mucking with the configuration.
When the handler executed the policy evaluation using: ExceptionPolicyManager.HandleException( dataEx, Policies.Data_Access_Policy ), the exception handling application block threw the Configuration Error: The type Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging.LoggingExceptionHandler, Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null from configuration could not be created.
In the quick start, it was mentioned that the Logging assemblies were needed if one used the logging handler but it didn't specify which assemblies. I had only added Microsoft.Practices.EnterpriseLibrary.Logging.dll
Upon closer inspection, it became obvious that I needed Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging.dll
The five assemblies I needed to make a reference to in order to use the block are: Microsoft.Practices.EnterpriseLibrary.Common.dll,
Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.dll,
Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging.dll,
Microsoft.Practices.EnterpriseLibrary.Logging.dll
and Microsoft.Practices.ObjectBuilder.dll
Once I had the appropriate references, things worked pretty swell.
Policies
The hardest part was to understand what was intended with policies. A policy is basically anything you can define as a standard way in which you'd like to handle errors. The examples and documentation don't really extrapolate on this matter. I guess the author assumes you are pretty clear on this yourself. If you think about it, you probably are. There are probably only a few specific things you want to do when an error occurs, depending on the severity and context. You may want to log and continue. You may want to let the user know something happened. You may want to change the message to something friendlier or less sensitive. These are your policies.
Under each policy is a handler mapped to each configured exception type. The block will evaluate exception mappings from most specialized to most generic. If you specify a mapping and a handler for Oracle.DataAccess.Client.OracleException, this will be the handler that evaluates against your exception. OracleException inherits from System.SystemException (don't ask me why that is!), it will evaluate that next. If you have neither mapped in your configuration but have a policy for System.Exception, this will catch all.
Under each exception type is a handler. The handler may log, it may wrap the exception in a different exception (effectively masking the underlying details from the user), or it may replace the exception entirely (effectively restricting the underlying information from access to the user's screen, regardless of user interface implementation. Why would yo uwnat to do that? you may ask... I probably wouldn't have until I was given the power. If your business layer has a database issue, you may want to be very verbose on the details of the problem in the message of the exception. "Connection string 'suchandsuch' failed to establish a valid connection. Please check the connections section in configuration," for example. I have been hesitant to include too much information in an error message for fear the wrong person may get enough information to hack the system (too easily, anyway). However, the ability to replace the exception before it leaves the business layer is awesome! I can establish a policy that logs the original error, then replaces a verbose dataException with a generic appException containing a reference to the handling Identifier, that then maps back to the verbose log in the back end system. The user interface will not only display something user-friendly, it will link to the actual physical entry which was logged that the administrator has access to. If the problem isn't easy to resolve, a temporary policy change can allow the message to propogate to the screen for troubleshooting. This is all way too freakin' cool!
What's next?
more research, more experimentation, and a enterprise-wide push to use this stuff. I tried the previous Exception Management Application Block and was very excited. I couldn't really get much buy in from my peers, they each had their own approach, and I couldn't demonstrate compelling value for the migration to the block. This is different! This is truly brilliant, robust and complete.
I will try to post more about how I am using it. I chose to define policies in a centralized enumeration and excute the evaluations in a centralized method. This allowed me to make the Enterprise Library reference in one place and use the existing company core references to my adavantage. This also prevent typos in the policy name string and simplifies integration a little.
Lastly, I want to mention the unit tests that ship with the libraries. Take a look! There is a very cool Reflection Attribute aliasing bit that is quite enlightening. I hadn't seen it before. It aliases the Miscrosoft Unit Testing attribute syntax against the NUnit attirbute set. That indicates two things. The tests will run using either test framework and the Microsot Unit Test framework is completely compatible with NUnit. Good news because I'm getting pretty heavily invested in NUnit recently.
Good stuff Patterns people, keep up the great work!