On our last episode, Bullwinkle was still trying to pull a rabbit out of his hat and speak directly to the Microsoft.Sharepoint .NET library...

I spent so many hours on this one.  I was at the point where I've done all the analysis I could do and just hope that I would uncover some clue along the way.  I knew it was working on a staging server on my company's network but was not working on my development server here on my Office Network.

Then Makarov! Makarov! Makarov! provided me with the keys to the Microsoft.Sharepoint.dll Kingdom with a simple suggestion:

Has anybody tried to add <identity impersonate=”true” /> to the web.config?

Thank you Makarov, from me and all the other people who find this solution.  That did it!!!

And as to the question, why was it working on the Staging Server and not my Development Server?  Both of the sites' root directories were in subdirectories configured as separate applications under an IIS site root directory.  The configuration was identical, as were the web.configs.  But the web.config on the Staging server IIS site's parent directory had an <identity impersonate=”true” /> in it, the Developer Server's parent directory's web.config did not.  When I changed the impersonate to “false” in the parent directory of the Staging server, I got the error I was getting on Development.  I didn't think to check the parent web.configs.

This also fixed the problem I was having passing DefaultCredentials to a Sharepoint web service.

The URL to the original blog post is here, Part II is here.