Are .NET Web Service proxy classes safe to use as Singletons?

I am using a Visual Studio generated proxy class for communicating with a SOAP web service. The generated class derives from System.Web.Services.Protocols.SoapHttpClientProtocol. I find the class is expensive to instantiate, so I am considering modifying my factory method to return a Singleton instance of the class. According to the documentation, the class is safe for multithreading.

Does anyone have experience with reusing instances of thes开发者_StackOverflow社区e classes? Are there any negatives to doing so (i.e. connections left open, etc.)?

.NET Framework Version: 2.0

---

There should be no reason that using these classes in a singleton pattern should cause a problem, however i am stuggling to unserstand what problem you are trying to solve. When you say these classes are expensive to instantiate what are you comparing them with? The cost of instantiating a proxy class should be neglible in comparison to the cost of making an http request to a web service. Could you explain the circumstances/post some code that demonstrates your performance bottle neck is being caused by instantiating the proxy classes.

---

I can imagine multiple reasons for instantiating a singleton of the proxy apart from the overhead, which I agree is not very much. The biggest reason would be to maintain session between service calls. Imagine an application that has multiple pages all of which use the same web service methods. Session for web service calls is usually carried out by setting a cookie parameter on the proxy:

proxy.CookieContainer = new System.Net.CookieContainer();

If you are creating a new proxy for each page operation, the session will be lost from page to page. Creating a singleton proxy used by all the pages would solve this problem.