In your binding configuration, there are four timeout values you can tweak:
<bindings>
<basicHttpBinding>
<binding name="IncreasedTimeout"
sendTimeout="00:25:00">
</binding>
</basicHttpBinding>
The most important is the sendTimeout
, which says how long the client will wait for a response from your WCF service. You can specify hours:minutes:seconds
in your settings - in my sample, I set the timeout to 25 minutes.
The openTimeout
as the name implies is the amount of time you're willing to wait when you open the connection to your WCF service. Similarly, the closeTimeout
is the amount of time when you close the connection (dispose the client proxy) that you'll wait before an exception is thrown.
The receiveTimeout
is a bit like a mirror for the sendTimeout
- while the send timeout is the amount of time you'll wait for a response from the server, the receiveTimeout
is the amount of time you'll give you client to receive and process the response from the server.
In case you're send back and forth "normal" messages, both can be pretty short - especially the receiveTimeout
, since receiving a SOAP message, decrypting, checking and deserializing it should take almost no time. The story is different with streaming - in that case, you might need more time on the client to actually complete the "download" of the stream you get back from the server.
There's also openTimeout, receiveTimeout, and closeTimeout. The MSDN docs on binding gives you more information on what these are for.
To get a serious grip on all the intricasies of WCF, I would strongly recommend you purchase the "Learning WCF" book by Michele Leroux Bustamante:
Learning WCF http://ecx.images-amazon.com/images/I/51GNuqUJq%2BL._BO2,204,203,200_PIsitb-sticker-arrow-click,TopRight,35,-76_AA240_SH20_OU01_.jpg
and you also spend some time watching her 15-part "WCF Top to Bottom" screencast series - highly recommended!
For more advanced topics I recommend that you check out Juwal Lowy's Programming WCF Services book.
Programming WCF http://ecx.images-amazon.com/images/I/41odWcLoGAL._BO2,204,203,200_PIsitb-sticker-arrow-click,TopRight,35,-76_AA240_SH20_OU01_.jpg
The difference may seem slight, but even with the ServiceLocator, the class is still responsible for creating its dependencies. It just uses the service locator to do it. With DI, the class is given its dependencies. It neither knows, nor cares where they come from. One important result of this is that the DI example is much easier to unit test -- because you can pass it mock implementations of its dependent objects. You could combine the two -- and inject the service locator (or a factory), if you wanted.
Best Answer
You'll need to implement a combination of custom
ServiceHostFactory
,ServiceHost
andIInstanceProvider
.Given a service with this constructor signature:
Here's an example that can spin up MyService:
Register MyServiceHostFactory in your MyService.svc file, or use MyServiceHost directly in code for self-hosting scenarios.
You can easily generalize this approach, and in fact some DI Containers have already done this for you (cue: Windsor's WCF Facility).