Follow up on my presentation in TSPUG (20/June/2007)
1) For PDF version of the slides click here.
2) All the code snippets are zipped into a file which can be downloaded from here.
3) Follow up on questions which were not answered:
Question 1) A gentleman mentioned that they are getting “The underlying connection was closed…” after a while when they call a sharePoint web service. I asked him to follow up on this with me later on , but it seems that our guy is so busy so I went ahead and replicated the same problem on my end.As I mentioned in the session too, this behavior can occur for a number of reasons. From not having access to call the web service to not having the proper ACL on the asmx file itself. Fortunately, his problem is more specific because he can call the web service for a while and then it fails so it clearly shows that it is not an access issue. I could replicate the issue when I called the web service from a windows form application which was behind a http proxy server. If I call the same web service not through the HTTP Proxy, the call goes through with no problem and it will stay alive forever – I tested my call the day after and service was still alive. When calling without using the HTTP Proxy, Web service is fine for the first few hours/calls and then it dies and returns the same error message they are getting. Here is my 2 cents on this. I hope this helps:
I solved this issue by altering the generated proxy class. In that generated proxy class there is a method called “GetWebRequest” with the following signature:
protected override System.Net.WebRequest GetWebRequest(Uri uri)
Change this method to:
protected override System.Net.WebRequest GetWebRequest(Uri uri)
{
System.Net.HttpWebRequest webRequest = (System.Net.HttpWebRequest) base.GetWebRequest(uri);
webRequest.KeepAlive = false;
return webRequest;
}
Setting KeepAlive to false may result in sending a “Connection:Close” header to the server each time you initiate the call and I believe that more processing is required on the server, so think twice before sticking to this solution. If you are okay with this performance hit that you may experience then go for it.
Question 2) Second question was made by one my colleagues about UpdateSystem method.SDK clearly states that this method is a kind of silent/anonymous update without leaving any foot trail behind. I can see many places that using this method is proffered over ordinary “Update()”. One of them is when you run a process to adjust some fields in the items of a list and you don’t want the “modified by” and “modified date” to be changed to your process account and the date and time the adjustment was made or even you don’t want to release another version if versioning is in place. That was an interesting one and managed to be added to my top tips for writing better code in sharePoint 🙂