What's your experience of Microsoft Application Blocks

Question

What is your real world experience with the Microsoft Application Blocks and other Microsoft solutions as opposed to writing your own solutions?

I started a new project and decided to give them a go. I used the exception handling and logging blocks. The exception handling block works well for what I needed. The logging block did 95% of what I needed, the rest needed to be customised. It took a while working out how to customise it, and then had some version reference issues. Logging is an very simple task whether it's writing to a file or database (in this project both). In hindsight it would have been quicker to write my own.

The project also requires synchronising data with a PDA. With a bit of research it seemed clear the direction Microsoft was pointing was Synchronisation Services. After spending about 3 days trying to get all the right versions of the different pieces of software I could not get the sample working http://stackoverflow.com/questions/771357/windows-mobile-synchronization-error. I opted to using the simple OpenNETCF Desktop Communication to copy files to/from the pda, use binary object serialisation, and write my own basic synchronising code which took less time and does everything exactly they way I want it (and don't it feel good : ))

Some positives:

• Don't have to reinvent the wheel
• Benefit from updates
• Benefit from other tools designed to work with them
• Large user base increases feedback, testing and robustness
• Good to have on your resume
• A new developer added to the team may be familiar with them
• Provide a lot of customisable functionality

negatives:

• over-engineered, try to be a swiss army knife, providing far more functionality than is ever needed for one solution creating complexity.
• even so, they never seem to meet all the requirements of the project, the tail can end up wagging the dog. I guess this depends on how much sway you have on how the application works.
• need to learn how to correctly implement the application block (ok, so this only needs to be done the first time they are used, so it's no biggie)
• increases dependencies on different dll versions, a bit of this goes with that
• large and cumbersome (not really an issue these days)
• difficult to customise due to their complexity

This has been my learning experience and will allow me to be better equipped to make a decision on whether to go with the Microsoft solution (or other 3rd party solutions) versus writing my own.

How about your experience?

Answer 1

I haven't actually used any of the application blocks in practice, but I've read through the documentation and looked at samples. In my opinion, they might be a good resource when something has to be done very quickly, but otherwise, it's a good way to back yourself into a corner when Microsoft releases an update that doesn't necessarily work the way you want it to.

I've always found it best to write my own logging and exception handling facilities. That way, I decide what gets added and removed depending on the needs of my application. As for reinventing the wheel, that doesn't bother me so much. I'd rather build something to my specifications, rather than use something built to the specifications of the general programming community that I have to hack up.

Answer 2

I haven't used them much, primarily because something else more powerful has swayed me from it. For example, when dealing with exceptions I went with CodePlex.Diagnostics, a nice package that logs stuff on the SQL Server. Very simple and useful for a web app. For logging, I use log4net under the control of Log4PostSharp. Of course, I use PostSharp instead of PIAB, if only because precompilation is, by definition, faster than dynamic proxies.

One cool thing is the Unity application block: it seems to have taken some of the lessons learned by other DI frameworks to heart, and is actually fairly easy to use (of course, there's PostSharp4Unity too).

Answer 3

They're over-engineered and it was my biggest issue with it, at the end I got rid of it and don't use it any more.

They are not useful enough, requires too much configuration, modification in the system and they keep changing stuff in them. To simply add a logging functionality you end like spending a 2 days to get it right.

There are libraries out there which works in 10 minutes as you would expect.

Answer 4

The Data Access and Exception Handling Blocks (only 2 I have used) are excellent if you aren't looking for anything above and beyond basic features out of the box. Sure there are other more powerful frameworks, but with minimal configuration and a very shallow learning curve, you can get these 2 blocks up and running in no time.

And since they use the factory pattern, they are easily extensible if you need to. We customized the Exception Handling block to show all kinds of Active Directory data along with the Exception being thrown. It has cut our support time down by a decent chunk.

Answer 5

Do you have a single application to maintain? Check if an AB (or any other components out there) can help you, test 'em, and use'em if they pass muster, otherwise not.

Do you have a large and growing set of applications to maintain? Then you're either going to build the same kind of code to deal with e.g. logging, authentication & authorization, remote communication, and similar recurring issues (exactly what depending on your business and IT environment); roll your own code or components to address the issues (and maintain it!); or use something off the shelf. One of these approaches usually (if not always) tends to work better with a large number of applications, and job rotation within your company. Guess which! (In particular, never underestimate the time it takes to train a new developer/maintainer to be productive in a 2+ year application with no similarities to or shared components with other stuff they've worked on before!)

My use of MS application blocks was several years ago. At that time, the exception handling block and the database access block helped quite a lot; the logging AB was reasonably good (though I preferred log4net for its fine-grained control); and most of the current AB's weren't there. My view is that AB's address shortcomings in the current framework. If they are successful (and really address existing pain points), you should consider it likely that they will be moved into future versions of the framework, or that the language and/or framework will be extended to address the pain points directly.

Code is never over- or under-engineered by itself, only for a particular purpose. The big challenge with evaluating off-the-shelf components is finding out what that purpose actually is, as opposed to market-speak or over-optimistic save-the-world-and-the-kitchen-sink manifestos. MS' P&P group seems far removed from the product development teams, and occasionally address the wrong problems with insufficient insight into recent product versions...

Answer 6

I haven't used them since .NET 1.1 / early .NET 2.0 and it was very limited with the Application blocks for Data. To be honest I haven't really considered using anything lately and I should look and see what they have currently.

In practice for me it has been easier to write my own solution. Typically I am seeing some pretty specific cases and I did have to jump through a few hoops to get things to work the way I wanted. Then again I was doing more ASP.NET stuff then (which it seems like there are a lot of hoops with web development in general) and I am mostly Windows Applications now, which seems a little more straight forward.

I think it really needs to be a case by case basis. If it works for you and meets your needs use what is there. No need to spend time re-creating something when a perfectly viable solution is there. Also there is no reason that you have to update unless you change framework versions, etc if they release a new version of the DLL. In my experience anyway.

Answer 7

We're using Unity with some success. I'm opposed to DI containers in general, but if you have to use one, Unity works well enough.

I'm less convinced about most of the others. The logging library in particular has been driving me nuts. Huge and overengineered, and yet hardcoded to some specific (and simplified) scenarios, requiring you to reimplement silly amounts of code to actually extend the library with some fairly obvious functionality. And the documentation is sketchy on how to customize and configure it, beyond the absolute basics.

I don't see much benefit in the Data Access block either.

On the whole, I'm not a big fan.

Answer 8

We're using logging, exception handling and validation blocks.

My experience with the logging AB has been similar to yours: it gets you 95% of the way there. Customizing is not easy, and leads to all kinds of overhead (updating, testing on unknown territory,..). Overall though, I don't think it would've been faster rolling my own, especially since the configuration options come in very handy (not so much during development, but when it's deployed, I really like having the editor and turning on/off filters at runtime etc). I did write a little wrapper around it, as I've found it offered lots more options than we needed (e.g. separate severity/priority - what's the difference again? etc).

Exception handling we used for a short while but threw it out. Ultimately we tought it was too much configuration. Configuration in app.config has a major issue: it's not modular (i.e. you can't easily merge configuration coming from different sources).

Validation: not a big fan. For no particular reason, just wasn't applicable much.

So, in the end, we only really use a customized Logging AB. Draw your onw conclusion on how useful the whole thing is ;)

So I would agree that the AB's are not really guidance - they offer a wide range of options and you need to make up your own mind on how to use it.

We've had bad experience using CAB (Composite UI AB). Unfortunately we're too far along to change it now, but if I would do the same project again, I wouldn't use CAB at all. It just doesn't seem to do quite what we need, so it's more in the way than anything else, and it obfuscates a lot of what's going on.