Monthly Archives: July 2005

True != true … duh!

Posted on by • Posted in BizTalk • 2 Comments
Ok … so once again one of the simplest of errors put me into out-thinking-myself mode.  Simply put, when you have a boolean in an XML file that goes into a BizTalk Orchestration, it is case-sensitve.
 
So if you get an error stating that you have invalid text for your System.Boolean type then now you know: "True" is not true … "true" is true.
 
Put this on under the "duh" category.
Advertisement

Using Jalindi Igloo plugin (CVS) with VS.Net … successfully

Posted on by • Posted in Visual Studio.Net • 6 Comments
If you need to use CVS for source code control on your Visual
Studio.Net project, here is a quick way to enable the latest version of
CVS in combination with the free Visual Studio.Net add-in: Jalindi Igloo.
The
plugin does have it’s own install program and scripts but the problem
is that it uses an older CVS library and does NOT work well with SSH
connections to a CVS repository. While the older version may work
well for you, I certainly suggest you always use the latest CVS client
for at least security reasons.
First, download all of the following packages:

Next,
install the CVSNT client as you normally would making sure to note the
location of the install directory. Once that is installed, open
the beta version Igloo archive and copy the files into the CVSNT
directory (ignoring the paths). But first, please note:

*** DO NOT OVERWRITE ANY FILES IN THE CVSNT DIRECTORY ***

The
beta igloo client has some older CVSNT files and you don’t want to mess
up your install. After that, you just need the nice VBS scripts
provided with the release version of Igloo. One script will
register the plugin as your SCC provider in VS.Net and the other will
restore SourceSafe as your client.

Problem naming a BizTalk operation ReceiveMessage or SendMessage

Posted on by • Posted in BizTalk • 1 Comment
Here was a strange one that took me a while to nail down.  First, the error messages:
The keyword new is required on ‘Microsoft.Samples.BizTalk.SendMail.ReceivePortType.ReceiveMessage’ because it hides inherited member ‘Microsoft.BizTalk.XLANGs.BTXEngine.BTXPortBase.ReceiveMessage(int, Microsoft.XLANGs.Core.Envelope, Microsoft.XLANGs.BaseTypes.XLANGMessage, Microsoft.XLANGs.Core.Correlation[], Microsoft.XLANGs.Core.Context, Microsoft.XLANGs.Core.Segment)’

‘Microsoft.Samples.BizTalk.SendMail.ReceiveSend.ReceivePort’ denotes a ‘field’ where a ‘class’ was expected

Static member ‘Microsoft.Samples.BizTalk.SendMail.ReceivePortType.ReceiveMessage’ cannot be accessed with an instance reference; qualify it with a type name instead
‘Microsoft.Samples.BizTalk.SendMail.ReceivePortType.ReceiveMessage’ denotes a ‘field’ where a ‘method’ was expected
After searching for a few hours on the Internet for that one and playing around with recent changes I had made I finally had realized what I did:  I was getting a little too creative for my own good (or not creative enough, perhaps). 
 
I decided that Operation_1 and Operation_2 were not good names for my receive and send ports so I decided to name them something else.  Of course, in a burst of creativness I used ‘ReceiveMessage’ and ‘SendMessage’ for the names.  I had done that a while back but apparently never did a build as I made several other changes since.  Then I compiled and got the errors above on the receive port.
 
Figuring it had something to do with the ports I decided to just nuke them and recreate them.  I used my usual internal justification that Microsoft’s software had somehow screwed up my code (uh … it never turns out that way).  After doing this everything compiled just fine once again.  Ah Ha! It was Microsoft screwing up my code! Then I immediately went and renamed the ports once again to my ever-so-creative names and boom. 
 
DOH!
 
Moral: Either get very creative with your naming or have a complete lack of creativness altogether.  Don’t sit in the middle.