Santosh Benjamin

BTS Diary 9 - EntLib - Is it really reliable?

Before anyone takes umbrage, let me add to the title " in the context of BizTalk 2004 projects".

This is the scenario. I've posted a long time ago about how we configured enterprise Library logging for our BTS project after reading up various articles (including a really well written one from Andy Morrison). Now we have Virtual instances that are exactly the same for DEV and TEST. When we first configured it we had everything smoothly running  and everyone was smiling. Then, one day, the penny dropped. We got a nasty error message in the event log saying that the system couldnt locate the loggingConfiguration section anywhere. Thinking it might have something to do with versions and the GAC we changed all version numbers, made sure there were no wildcards in the assembly version numbers, recompiled everything and the problem stopped for a few days. Some days later it resurfaced. We narrowed down the incidence to our custom pipeline components, did the rebuild and re-versioning, but it didnt work. So we took the easy option and removed logging from our pipelines. This seemed to work. The time then came to move stuff to TEST and what do you know, the gremlins surfaced again, but this time only on TEST (DEV worked fine). Rebuilding, reversioning didnt help.

We took a look at log4net last week since we are going live in a weeks time but the amount of coding and configuring it would take is not worthwhile (even incorporating Scott Colestocks log4net work is too much).

We couldnt use TraceListeners either because for some reason as soon as you put a custom trace listener section into BTSNTTSVC.exe.config, the BTS host just drops dead.

Havent read about any problems with BTS and EntLib so i guess Andy Morrison and others must be extremely lucky, or we are just dim or plain unfortunate (or maybe both).

So now we are stuck. We cannot go live with the EntLib since its so unreliable. Cant have the business process working smooth but everything to cease just because the logging doesnt work can we? And unless it can be tested and verified on all environments, we cant ship. The final option we coded in yesterday was to use a simple file appender. If there is any threading type exception caused by multiple orchestrations firing up and trying to write to the file, we just suppress the exception and this way we get 'good enough' logging.

Why cant MS just design some AOP type logging into BTS? How difficult is it to add a property to an orch to say which log file it uses (if its critical enough to warrant a separate one) or shares with others? How about a provider that automatically takes care of reading configuration info from SSO (as shown by the SSOConfig written by Jon Flanders)? Yes i know. BTS and EntLib are from separate teams but surely by now its obvious that folk need to use them together and this should be enough to warrant a joint effort and some P&P stuff to go with it to allow these two pieces of software to interoperate? Maybe they will someday but as for me and my team its goodbye to EntLib and i shall solemnly warn other teams and the folk who read this blog to tread very very carefully when using BTS and EntLib together. I dont think the hassle is really worth it.