Sunday, January 27, 2008

Visual Studio 2008, .NET 3.5 and ILM 2007

When pinging the product group to determine whether or not we'd see any compatibility issues with compiling the ILM 2007 rules extensions under the .NET 3.5 Framework I got the virtual shoulder shrug - "should be ok" reply and "it hasn't been tested yet. Given that these folks are mostly heads down pounding out the the updates to ILM "2" I can't really blame them. I'm here to say that so far my initial tests have yielded excellent results with no issues discovered so far. That is compiling all rules extensions under the 3.5 framework and successfully being able to attach the debugger.

Visual Studio 2008 has the ability to compile a project under 2.0, 3.0, or 3.5 frameworks known as "multi-targeting support" so if you're truly concerned you should take the 2.0 route but it is safe to update your solutions to Visual Studio 2008 (version 9.0). The new version has some much needed improvements in and around IntelliSense support for more languages (like Javascript for example) but the bulk of the improvements come from the updates in the 3.5 framework (C# 3.0, VB 9.0, ASP.NET 3.5, etc).

For some additional guidance on features available in .NET 3.5, check out the following titles:

Beginning C# 2008: From Novice to Professional
by Christian Gross

Beginning VB 2008: From Novice to professional (Beginning: from Novice to Professional)
by Christian Gross

Introducing Microsoft LINQ
by Paolo Pialorsi, Marco Russo

Friday, January 25, 2008

Using Extension Methods in VS2008

So I've been sitting in this Introduction to Visual Studio 2008 course delivered by an excellent instructor from IT Mentors as part of the Microsoft Partner readiness program and certainly the first thing to strike me as really useful in my daily life as an IDA guy is the introduction of Extension Methods. Now, I'll leave the technical details to a of the topic as there are many examples and excellent breakdowns. The question is, is anyone else other than me really thrilled about the chance to do the following:

csentry["UTCAttr"].Value = mventry["attrib"].Value.ToUTCCodedTime;

The wise and learned should spot instantly that there is no "ToUTCCodedTime" method for Value (inherits from string class) so how would such a thing be possible. The answer - Extension Methods.

If there is any interest I'll post my code tinkerings for adding ToUTCCodedTime as an Extension Method.

The other cool thing I'm taking away from this class - my first real exposure to LINQ. I'm thinking definite XMA potential here boys and girls!

Saturday, January 12, 2008

Throw New DeclineMappingException

No, it's not something you do when you don't get the punch line to a joke (that's for you Craig).  It is probably a pretty misunderstood exception so I thought I take a few moments to impart some words of wisdom and it wouldn't be my blog without a nifty matrix (because everything is more helpful in a matrix).

As usual, I wouldn't be speaking about this if this one hadn't already bitten me good some time ago.  It looked easy, anytime I didn't want to flow something I could just throw this little exception and MIIS would immediately stop processing the flow - so I started using it everywhere, it became my new ELSE directive!  I was very pleased with myself because every code path was accounted for, errors were trapped, data was being moved, or the exception was thrown.  However, as they say, it works well in PowerPoint...

I started to wonder why data wasn't flowing the way I had anticipated in some cases - especially in my manual precedence rules which I'd spent quite a bit of time on tying up all those loose ELSE conditions.  You see, sometimes the right thing to do is to flow nothing at all (leaving the existing value intact) and that's exactly what DeclineMappingException doesn't do.  Let's take a look at how this breaks down but first let's set up the situation.  The matrix below is comprised of three rows and two columns.  The rows are what you choose to do during an attribute flow, so for "contribute" you actually wrote the data to the opposite entity (cs->mv or mv->cs), "no contribution" you didn't write anything, the rule just exits without doing anything and you guessed it with our "Throw" buddy.  For the columns we have a special treat - in the first matrix they represent what happens between two different precedence configurations.  With "Standard Precedence", the attribute is not configured for "Manual Precedence" and there is more than one source that can contribute the data. 

  Standard Precedence Manual Precedence
Contribute Value is contributed Value is contributed, although it can be overridden by another rule later in the sync
No Contribution Existing value remains Depends on other flows
DeclineMappingException Next precedent source contributes Next precedent source contributes

The next table contrasts what happens when you contribute a value and the data has either changed or remained the same.

  No Change Data Changed
Contribute Engine must evaluate that the data has not changed Engine evaluates the change and contributes the new value
No Contribution Existing value remains Changed value is never contributed
DeclineMappingException Next precedent source contributes Changed value is never evaluated, the next precedent source contributes

So, the real reason for the DeclineMappingException is the last cell here - you threw the exception despite the fact that the data had changed you decided that for whatever reason you want the next precedent source to be able to contribute.  Under standard precedence rules the next source in line would contribute and with manual precedence the rule would have a chance to contribute.  Let's not even touch what happens if you tell multiple rules to contribute under manual precedence (ok fine, last in wins).

I think in some cases you, like I did, found yourself throwing the exception under one of the No Contribution conditions hoping to save the engine a cycle or two - but it has the wrong effect.  I use following rules to help keep this straight:

  • If you don't want to contribute a change but you want to leave the existing value (from this MA) in place, then do nothing
  • If you want to force the next precedent source to take a crack at this (regardless of precedence settings) and the existing value should not remain then throw the exception

Let me be clear here on the last point, if I throw the exception and none of my other sources have anything to contribute then the value is deleted - you don't get the old value back!

If you came across this because you were searching for code examples of manual precedence then let me at least reward you for reading through this entire post just for this one link.  Oh,and one more from Joe's Blog.

Newer Posts Older Posts Home