Yossi Dahan [BizTalk]

Google
 

Monday, July 16, 2007

Orchestrations and the Obsolete attribute

I've recently posted this message; which meant we had to go back and change quite a few methods shared between quite a few orchestration.

considering the size of our project finding all the places that needs changing was not a simple taks, nor could we break the interface and assume we'll find and fix all the places before our next build is due; a more planned and carefull appraoch was required and so we've decided to add the Obsolete attribute to the offending methods and overload them with ones that take in XlangMessage to be used everywhere.

We were hoping that adding the attribute would result in nice warnings appearing in every build that uses the obsolete overloads which would help us identify, and eventually change them all.

However, to our surprise, BizTalk (in the most general term one could use 'BizTalk') is being a bit inconsistent in it's handling of the Obsolete attribute -

If we use a method called MyMethod in an expression shape in an orchestration, and we add the Obsolete attribute to the method -

[Obsolete("Some Message Here")]
MyMethod(XlangPart part)

When we build the orchestration we don't get any warnings as we'd expect which makes the Obsolete attribute quite useless (and is very inconsistent with .net in which, obviously, the use of the attribute is supported)

Whats strange is that if we change the attribute to raise an error -

[Obsolete("Some Message Here",true)]
MyMethod(XlangPart part)

Not only we see this error when trying to build the orchestration we would also see any other WARNINGS caused by the use of the attribute elsewhere in the project. suddently they are all visible.

Labels: ,

0 Comments:

Post a Comment

<< Home