We've recently started using BizTalk to communicate with an SMS provider on the Internet to allow us to send and receive text messages. While setting this up, we encountered some very random error messages that didn't make sense in the context given.
Error 102: Static member 'CommsRouter.com._2sms.www.SMSService_.SMSService.SendMessage' cannot be accessed with an instance reference; qualify it with a type name instead
Error 103: 'CommsRouter.com._2sms.www.SMSService_.SMSService.SendMessage' is a 'field' but is used like a 'method'
It turns out, after a little bit of searching around the Internet that this seems to be a rare (but thankfully not unique) problem. This was the first (and only) blog post I came across about it, and suggests that it's a problem with BizTalk... surely not? Well Jason, you're not alone in this. It seems that BizTalk uses SendMessage and ReceiveMessage internally to handle some sort of message box stuff, and as they are static methods they conflict with anything else that tries to implement a method with the same name.
So what to do? We have a reference to a webservice within BizTalk that contains a method name that refuses to compile. My first guess comes from a C# developer's background. When you add a reference to a web service what really happens is that a magical tool goes off in the background and generates you a proxy class that implements all of the methods of the webservice and allows you to call it from normal code. Surely a similar thing must happen in Biztalk? Sort of...
The file generated is an odx file (BizTalk Server Orchestration) and is full of XML. However, a quick peek through this revealed that it basically does the same thing. It exposes some method names and shows which webmethods are called behind the scenes. Simply renaming the methods shown to BizTalk was enough to get our solution off the ground.
However, this was a bit of a hack, and wouldn't survive anybody pushing "Update Web Reference" on the webservice, so we found another way round.
It's a bit disappointing really, as it's a relatively simple solution. We made a Class Library (DLL) project and housed the web reference in there, and then wrapped the one call we need (and called it something a bit more descriptive than SendMessage!)
Lesson learned for today though: Don't try and use SendMessage and/or ReceiveMessage in your own orchestrations or custom libraries!