This is a follow on from my post about BizTalk reserved keywords.
I emailed 2sms.com about our BizTalk problem with their service the other day, and 6 days afterwards (not 6 working days, 6 actual days) we had an email response back from them saying the following:
Good morning,
I am writing regarding your support email that you sent last week regarding Microsoft BizTalk. I understand that you have adapted to problem of the name ‘send message’ not being recognized. Just to let you know we have taken your feedback on board and we have added an option for others who have this problem.
On our developers page on the website, when you click on web services, in the service URL, if you change the 1.3 to 1.4, the name has now been changed to ‘sendindividualmessage’ allowing the name to be recognized.
Thank you for your feedback on this, please do not hesitate to contact our support team with any further feedback or queries.
Now if that's not a company worth doing business with I don't know what is!
(Please note that this post does not necessarily represent the views of my employer and all that nonsense, I'm just really impressed that we got a shiny new release of their webservice just for us! :))
...to get you to read the instructions!
In the past, the following error message "the project location is not trusted" has not caused many problems. There's been a little utility called the .NET Framework 2.0 Configuration mmc snap-in (gotta love Microsoft and the names that the marketing department come up with). However, someone made a decision to not include this tool in Vista. It was obviously proving far too useful and having a positive impact on people's productivity, so out it came </rant>
After some careful Googling around the Internet, caspol.exe was found to do a similar job. However I couldn't get it to work. I tried for about 5-10 minutes before eventually asking for help. Was pointed in the direction of the instructions, told I was doing it wrong, and then the problem was solved. How is it that someone who knows nothing about .NET, Code Access Security Policies and the technical differences between XP and Vista can point out that I've not included as many parameters as I needed to at the command line!?
For future reference though, the link is here (and it's a very picky program)!
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!