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.
I'm probably a little late to the party, but if there are others out there who havent read this before, go and take a look at Scott Bellware's post. MS recently published (and promptly took down ) an article outlining guidelines to TDD and created a huge storm of protest. As Im not an expert on the subject, all I can say is that Scott's post and the comments to the same as well as others on sites such as ObjectMentor have explained quite painstakingly why the MS bunch who wrote this have scr**d up.This is quite a pity as i was hoping the 'recognition' of Agile Development in VSTS would actually help the developer community instead of some folk trying to force a VS view of the world into development. Whats even more disturbing is how this conflicts with some of the well written articles from the P&P folk and other good bloggers from MS.
But one of the most interesting statements from Scott is as follows: "You simply cannot achieve the aims of Test-Driven Development if you start with sweeping assumptions of the structure of classes before you set down the kind of code that incrementally validates your assumptions.
If a developer leaps to conclusions about design of a class or family of classes, he will have missed the optimal design of the class. As the implementation of a class deviates from its inherent optimal design, implementation and maintenance costs for that class increase exponentially as the effort to cajole misshapen classes together into a system of misshapen classes increases. This increase in cost an effort is compounded by the number of classes in a system. Most codebases can’t sustain this pressure for too long and they are often disposed of and re-written entirely from scratch – using the exact same development methodologies that caused them to degenerate into entropy to begin with. "
I think thats a great way of putting it.
Just came across this post on the subject. Thought it had already been done to death. I' d say one thing though. Its very easy for most VB (pre .NET) folks to continue doing procedural programming when they move to VB.NET since they have a largely familiar environment. Note, this does not apply to good programmers and those who understand and appropriately apply OO. Getting VB programmers to move to C# shakes some of them up a bit and causes them to get a little more into the OO world which, within the service boundary, is still a great way of designing maintainable programs. If I had a choice in the matter, when working with a team of existing VB programmers, I would plump for moving to C#.