SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

When trying to access SharePoint WSS 3.0 server using the web services API, the software service we are developing will hang anywhere between 30-60 seconds when making any call (pick anyone of them, it doesn't matter) against the server for the first time. After this first call is made , each request thereafter is very quick.

This happens on both the local dev install of SharePoint, or against the production SharePoint environment, same results no matter what we try.

When accessing the SharePoint site (both local dev and production) via a web browser, using the same log in credentials as being used with the WSS API, there is zero lag time during the authentication process. But as soon as we try to access the list via VS 2010 it hangs for 30-60 on initial contact, then as stated it is smoking fast thereafter.

It seems to be an authentication issues, but for the life of me I cannot figure it out.

This is the code being used via C# to authenticate to SharePoint WSS:

_lists = new Lists
       Credentials = new NetworkCredential(UserName, Password, Domain),
       Url = string.Format("{0}/_vti_bin/Lists.asmx", BaseUrl),
       UseDefaultCredentials = false
   }; // Reference the list object.

Once the code hits the line below it hangs for 30-60 seconds.

the GetList(string listName) 


Any call thereafter is extremely fast.

One last note. When trying to access the service via Visual Studio, we receive the popup dialog to enter credentials, Discovery Credentials, and it will not authenticate, but we are able to retrieve the list of services. This occurs on both the production and test environments.

Please see images in order of events for adding a web service:

enter image description here

Next we get three dialog for list, error and meta data and none of them validate.

Close Up for First screen:

enter image description here

enter image description here

enter image description here

We finally hit cancel.

enter image description here

And can see the calls we can make against the service:

enter image description here

I have even tried the look back hack and no dice.

Update: After reviewing the recommendation here I tried them each and I even ended up caching the credentials as this:

_lists = new Lists
        Url = string.Format("{0}/_vti_bin/Lists.asmx?WDSL", BaseUrl),
        UseDefaultCredentials = false
    }; // Reference the list object.

    //Create an instance of the CredentialCache class.
    CredentialCache cache = new CredentialCache();

    // Add a NetworkCredential instance to CredentialCache.
    // Negotiate for NTLM or Kerberos authentication.
    cache.Add(new Uri(_lists.Url),"Basic", new NetworkCredential(UserName, Password, Domain));

    _lists.Proxy = null;
    _lists.Credentials = cache; // new NetworkCredential(UserName, Password, Domain); //cache;

Yet, the call is made to get the Sharepoint List Data and the lag time is still 30-60 seconds, and then each call thereafter on the same connection is fast via the WSS.

But, if I restart the command line app within a few seconds retrieving the list is almost instant, but it I wait wait 5 minutes, then the 30-60 second lag time again. This is really frustrating and I am at a loss.

Anyone have any more ideas?

share|improve this question

My first step here would be to break out Fiddler2 and try to analyse the request/response data going back and forth between SharePoint and VS. This should give you a clue as to where the problem is occurring.

share|improve this answer

There are a couple of things which you could check.

  1. As @AmitKumawat has suggested, there might be proxy settings which is blocking from accessing the services.

  2. It could be a loopback issue which could be solved following the kb -

  3. Check for the IIS manager settings for the website, whether the valid authentication methods are used.

Check this post too which discusses about similar issues.

share|improve this answer
Thank you Deepu. I have the proxy set to bypass and also turned off the loopback, still same issues. If the web browser, firefox or IE I go to the url and it is fast. No lag time. Whenever I try to make the call via the webservcives 3--60 seconds wait time every single time. any other ideas What authentication modes should be set? – nitefrog Dec 2 '11 at 6:30

It looks that the problem is related to proxy server settings. Explicitly assign proxy on webservice client using a WebProxy object as below.

 _lists = new Lists
       Proxy = new WebProxy ("", 808);
       Credentials = new NetworkCredential(UserName, Password, Domain),
       Url = string.Format("{0}/_vti_bin/Lists.asmx", BaseUrl),
       UseDefaultCredentials = false

If you don’t have a proxy, you must set the Proxy property to null on webservice client objects. Otherwise, the Framework may attempt to “auto-detect” your proxy settings, adding up to 30 seconds to your request!

Regarding Visual Studio, If you cannot add a reference to a Web service , it might be that the proxy server is not configured correctly. In Microsoft Internet Explorer, on the Tools menu, click Internet Options, click Connections, and then click LAN Settings. Select the Bypass proxy server for local addresses check box.

EDIT : Also VS 2010 selects .NET Framework 4.0 as default.So Please ensure you use .NET 3.5

share|improve this answer
Any other ideas? None of these seems to work... – nitefrog Dec 2 '11 at 21:16
did you assign correct IP and port of your proxy server? Also, ensure that it is set to null if you don't use proxy. – Amit Kumawat Dec 3 '11 at 6:30
@nitefrog,Please check you are using .NET 3.5 in VS2010 and not .NET 4.0 which is default. – Amit Kumawat Dec 3 '11 at 11:30
I have tried this is both .net 3.5 and 4.0 and both cause the same issues. I also set the proxy to null and no difference. Thanks... – nitefrog Dec 3 '11 at 19:10

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.