Matias Woloski’s Blog

Send an email when an exception is thrown using EntLib is not rocket science.

Here is a screen shot of how the configuration looks like

The steps involved are:

1. Create an Exception Handling App Block
2. Create a New Policy (for instance “Email Policy“)
3. Create a new type of Exception to manage on the policy. Using “Exception“ will catch every kind of exception thrown
4. Create a new Logging Handler for the Exception. Here the Logging and Instrumentation App Block will be added to the config.
5. Add the Email Sink on the Logging Block and configure it (from and to email address, etc).
6. Create a new Category (for instance “Several“) and add a new Destination
7. Configure the Destintation to use the Text Formatter and the Email Sink
8. Go to the Logging Handler node and set the LogCategory to “Several“

Here are the config files ExceptionLoggingToEmail.zip (2.91 KB)

Btw, sending an email is a task that requires some resources so
maybe It would be better to use the Async Logging as I described in the
last post. And let the distributor service to send the exception email in another process or server.

I’ve been experimenting with EntLib Logging App Block. I wanted to do the async logging via MSMQ.

Async logging is one of the requirements of Enterprise Applications that does not want to waste cpu cycles logging on the Event Viewer or raising a WMI event or whatever logging strategy they use. Instead, a better approach is write the log message to a MSMQ and then have a service polling that queue that will do whatever with this log.

This way we could have our logging in a separate machine and the applications just write to a queue (which in turns much more fast compared to other things). Indeed we could write to a queue on the same machine. Here we could be more performant because the logging runs in a separate process (with a Windows Service, a Console app or whatever that polls the queue and get the log message).

Enterprise Library takes care of all this for us and we could have async logging setup in a matter of minutes.

I will show here what I did to get it running.

Client Application

First, we need to create the Logging Application Block for our application. Right Click on App -> New -> Logging and Instrumentation Application Block.

Then we need to remove some stuff that the client application won’t use. The logging will be done by a separate service, no by the client application inprocess. We won’t need the Distributor Settings and we don’t need the InProcess distribution strategy. So right click on Distributor Settings -> Remove. And Right click on InProcess -> Remove.

Now, we need to add the MSMQ distribution strategy. Right click on Distribution Strategies -> New -> MSMQ. The MSMQ distribution strategy has a queue associated where the LogEntries will be throw. Click on MSMQ and modify the QueuePath to some message queue you want (remember to create the queue before using it!)

Click on Client Settings and choose MSMQ on the DistributionStrategy property.

MSMQ Distributor Service

EntLib provides a Windows Service (MsmqDistributor) that will poll the message queue within a configured interval and do the real logging. This service is not installed by default, nor via InstallServices batch. So we need to install it by ourselves.

Open a vs.net 2003 command prompt and do a

cd [EntLibInstallDir]\bin\

Then run the installutil

installutil MsmqDistributor.exe

Now we need to configure the Logging block in the service. Think now that the service config file is like your client application. Remember that the async logging has two process running: the client application itself (winforms, web, whatever) and the service distributor (the service that will do the real logging).

You will need to copy two files required by the MsmqDistributor config otherwise there will be a validation error (it seems like the PAG guys forgot to include them in the bin directory). So copy these two files

[EntLibInstallDir]\src\Logging\MSMQDistributor\loggingConfiguration.config to [EntLibInstallDir]\bin
[EntLibInstallDir]\src\Logging\MSMQDistributor\loggingDistributorConfiguration.config to [EntLibInstallDir]\bin

Now, open the [EntLibInstallDir]\bin\MsmqDistributor.exe.config with the EntLib console (you can use the same console that you were using for the client app, but if you are using separate machines obviously not

(it seems they forgot to change a path there [C:\Depots\Microsoft\ELF2\QuickStarts\Logging\CS\LoggingQuickStart\App.config]
Let’s configure the last thing! Right click on the Distributor Settings of the MsmqDistributor config file -> New -> MSMQ Distributor Service. This is the configuration that will tells the Windows Service which is the queue path where the logentries are being saved.
You should set the QueuePath in the property grid to the same queue configured in the client app (if you want it to work of course

Finally, you can configure whatever you want regards Formatters, Sinks and Categories here. Remember to do it on the service and not the client!

Save All, start the service, start your application and enjoy Distributed Async Logging!

I was reading the Andres Aguiar blog and found a post about ILOG. That’s a really cool product…

http://www.ilog.com/products/rulesnet/

How useful is the ASP.Net identity matrix? I’ve queried it a lot…

I created the same matrix for MBI 3.

The scenario is a client calling MBI 3 through DispDirect which uses the WebService transport. IIS configurations below apply to the FwkWebServiceTransport virtual directory. The variable means:

• Command = cmd.User.Login
  
• Thread = System.Threading.Thread.CurrentPrincipal.Name
  
• WindowsIdentity = System.Principal.WindowsIdentity.GetCurrent().Name

These variables are queried in an MBI business action.

Note: whenever the Anonymous is checked, it will override any other checkbox (integrated, digest, etc.)
Note 2: NT AUTHORITY\NETWORK SERVICE is the user that runs the ASP.Net worker process in Windows 2003. For older versions is the MACHINE\ASPNET user.