views:

1107

answers:

3

I have a Service Reference (not a web reference) in VS2008 to a web service that I did not write. The reference works, but only asynchronous versions of each method are available for me to use.

In the "Configure Service Reference" dialog, the "Generate asynchronous operations" is checked and grayed out. First of all, I thought checking this box generated async methods in addition to, not instead of, blocking methods. Second, I've never seen it grayed out before.

I have experience writing both sides of both WCF and ASMX-era web services and have never seen this before. What could be causing this?

Thanks.

+5  A: 

I'd be willing to wager ten up-votes that it's because you're doing this in Silverlight. Unfortunately I don't have the tools installed so I can't test this theory, but I do know that service calls from Silverlight can only be asynchronous. Perhaps you are using a Silverlight project template and are creating the service reference there? Visual Studio might be smart enough to know not to generate blocking methods in such a situation.

For reference:

http://msdn.microsoft.com/en-us/library/cc197937(VS.95).aspx

Randolpho
Really curious to see if you're correct. If nothing else, it's a great guess!
Terry Donaghe
You're right, it is Silverlight. I'm surprised I forgot to mention that. What is the reason for this? Obviously I am able to turn an async call into a synchronous call by immediately waiting for the response (is this a no-no?). It's just annoying. Why can't the generated code do that for me?
Greg
I believe the reason is that Silverlight executes in the browser's UI thread. If you block, the entire page could be unresponsive.
Randolpho
Yeah, I feel a little less smart now than I did when I initially wrote that comment. I don't even need to block in my case, and while I can think of a situation where you'd need web service calls, the second depending on the first, it's kind of contrived and the article linked by geofftnz helps.
Greg
@randolpho and you thought you'd gotten away from async nature of javascript didnt you. well i did :-)
Simon_Weaver
+1  A: 

Silverlight only generates async service calls. However check this CodeProject page out.

When I started working with Silverlight, it was something that threw me at first. Then I realised I should be changing my code to work with the async model. You dont want to be blocking the UI thread while you wait for a service call to return.

geofftnz
A: 

The Silverlight Plugin is running on the Browsers UI thread. If you did synchronous networking calls you would block the entire Browser UI thread. In Chrome this would result in a non-responding tab, in other browsers like IE, the entire browser would appear locked.

So by only supporting asynchronous networking you are forced to write your application in an asynchronous maner.

Jonas Follesø