Generics will break intellisense, so have some faith!
Sometime there are some BizTalk quirks that whilst not very harmful, can take along time to figure out, and so can really hurt productivity and get developers (and managers) very frustrated; they often happen when you’re taking a step or two away from the paved path, and do things a little bit more adventurous, but not to say not valid….here’s one -
We have a helper class we use in many orchestrations, call it class B.
It, in turn, inherits from the abstract class A, overriding a couple of functions, and leaving some unchanged, it does not add any new functionality.
When used in an expression shape in an orchestration, intellisense shows the two methods we’ve overridden, but does not show any other methods declared in the base class. This is just intellisense, though, keep typing, make sure you don’t make any mistakes, and the compiler will be happy with the ‘missing’ method.
Further more – make a mistake (wrong parameter, for example) and you’ll get the squiggly line with the correct error message and everything, just don’t expect to see the method and it’s signature in the intellisense drop down…
This took ages to figure out, with the developer first assuming he had done something wrong any tried everything to correct it, including the infamous close-VS-restart-VS, only when all things failed I suggested he simply keep typing and viola! how annoying is that?
Turns out we are to blame – for using Generics.
The base class is declared as
public abstract class A<T>
and the concrete class as -
public class B : A<[some other (enum) type here]>
This works fine with BizTalk 2006 – the member declared in the orchestration does not require any generic type so from a runtime perspective it all runs just fine; from a designer point of view there’s no problem declaring a variable of type B (as no generics are involved in this), but – as was evident – don’t expect to see anything from the base class in intellisense.