In my first post I ranted uncontrollably about some reasons why utilising MCMS legacy components within your applications is a really bad idea from a solutions architecture perspective. I’ve calmed down a bit since then – not much, but a little! However I did promise I would rant some more, so here it is…

Undocumented. The method signatures don’t count.
In part one of his excellent series on the topic, Stefan points out that it’s probably not prudent to rely on black box testing of an undocumented interface, as the 10,000th call could stuff your application good and proper.

Now of course for the particular components we are talking about, we don’t have to necessarily go to the lengths of de-compilation - Object Browser (or the new Class Diagram in VS.NET 2005) is extremely useful (yup, for legacy components too), but his point remains valid. Let’s expand the ‘not-documented’ argument a little further.

Say you are hacking about in your favourite reverse engineer wizard with one of the MCMS legacy components and stumble upon a nice looking method (e.g. AddUser(string bstrUserName, int lValue)).

You may assume that this is just the ticket for adding a user, and that it surely must do reasonable things like validating the user exists in NT before adding it to MCMS. Also, bstrUserName sounds like DOMAIN\User – but how do you know for sure? That could be a Distinguished Name, a UPN, a SID – or a switch of all the above. Sure you could test it a few times to find out, but this is dicey ground already.

In addition, this being undocumented there is no way of knowing if the correct usage of this involves a bunch of other work, for example:

• Is creation of a user allowed if there is no role group context first?
• Validate that the username is valid and exists
• Pass the username in as the string (the call above)
• Ensure some other method is called to commit changes
• Etc...

The point being not only is the interface undocumented, but so is the intended usage of its implementation. Those who are ‘allowed’ to use these components could easily have a very thick document detailing their correct usage including a sequence of calls to other components and even maybe some operations in the calling code block itself!

Shoddy you may say, and in comparison to the Interface based approaches to things these days (dare I say OO on this here blog!) you’d be right – but we all know this is extremely common.

If you’ve been poking around that nasty AEServerObjectLib.dll, then the chances are you’ve also been digging into the MCMS database (and possibly even ‘decrypting’ the sprocs). If so you’ll note that it’s actually pretty decent but in many cases integrity is enforced by the application. Take the above example again – if you don’t follow the correct usage for the legacy components, not only will your application from time to time shaft you, but your database will include inconsistencies, rendering it pretty much useless for operational service.

But damn it, I want that functionality.
There is an argument that as Site Manager provides some functionality, which obviously uses the legacy components, so why can’t we use it to? Adding fuel to the fire is the ‘dropping of the ball’ by not including various ‘functionality’ in the API. I empathise with these arguments to a degree, but it is much better that Microsoft focus on moving away from the NCompass legacy rather than knocking out another nasty wrapper API. The bottom line is that there is always a solution which doesn’t compromise the system, which is where attention should be focused, as opposed to moaning that the API sucks – let’s face it - is there a Microsoft Server product API which doesn’t have rough edges?


Codeheads get offa that thing
I took some abuse for upsetting codeheads in my previous post, but I’m not repentant! My argument is not that you should never ever ever ever touch this stuff. If you are interested in understanding how a system hangs together and want to have a play on a dev box, go for your life. As I said, from an academic perspective this is reasonable, although one should be careful to avoid licence and legal issues. My point is that you should never mess with legacy components and/or the database for a customer deployment as it is the customer who will suffer when the vendor cannot support them.


Legacy Components – just say no
My mate Kev, who builds big ass WSS hosting solutions summed it up best…
“You just end up delivering fragile systems to your customer and when the next hotfix, SP or upgrade comes along the rod for your back arrives a-knocking at your door. If the functionality ain't there in the API then let the vendor know and live with it until it does.”