UPDATE: I posted this question to MSDN here (http://forums.microsoft.com/Forums/ShowPost.aspx?PostID=2808543&SiteID=1&mode=1) and Michael Washam of Microsoft responded with a concise answer.
I created a web service to act as a BDC-friendly facade to a SharePoint list. When I used this from my development environment, it worked fine. When I migrated this to a new server, I encountered this error:
|System.IO.FileNotFoundException: The Web application at http://localhost/sandbox could not be found. Verify that you have typed the URL correctly. If the URL should be serving existing content, the system administrator may need to add a new request URL mapping to the intended application. at Microsoft.SharePoint.SPSite..ctor(SPFarm farm, Uri requestUri, Boolean contextSite, SPUserToken userToken) at Microsoft.SharePoint.SPSite..ctor(String requestUrl) at Conchango.xyzzy.GetExistingDocument(String minId, String maxId, String titleFilter) in C:\Documents and Settings\Paul\My Documents\Visual Studio 2005\Projects\xyzzy\BDC_DocReview\BDC_DocReview\DocReviewFacade.asmx.cs:line 69|
Here is line 69:
using (SPSite site = new SPSite("http://localhost/sandbox"))
I tried different variations on the URL, including using the server’s real name, its IP address, trailing slashes on the URL, etc. I always got that error.
I used The Google to research it. Lots of people face this issue, or variations of it, but no one seemed to have it solved.
Tricksy MOSS provided such a detailed error that it didn’t occur to me to check the 12 hive logs. Eventually, about 24 hours after my colleague recommended I do so, I checked out the 12 hive log and found this:
An exception occured while trying to acquire the local farm: System.Security.SecurityException: Requested registry access is not allowed. at System.ThrowHelper.ThrowSecurityException(ExceptionResource resource) at Microsoft.Win32.RegistryKey.OpenSubKey(String name, Boolean writable) at Microsoft.Win32.RegistryKey.OpenSubKey(String name) at Microsoft.SharePoint.Administration.SPConfigurationDatabase.get_RegistryConnectionString() at Microsoft.SharePoint.Administration.SPConfigurationDatabase.get_Local() at Microsoft.SharePoint.Administration.SPFarm.FindLocal(SPFarm& farm, Boolean& isJoined) The Zone of the assembly that failed was: MyComputer
This opened up new avenues of research, so it was back to The Google. That led me to this forum post: http://forums.codecharge.com/posts.php?post_id=67135. That didn’t really help me but it did start making me think there was a database and/or security issue. I soldiered on and Andrew Connell’s post finally triggered the thought that I should make sure that the application pool’s identity account had appropriate access to the database. I thought it already did. However, my colleague went and gave the app pool identity account full access to SQL.
As soon as she made that change, everything started working.
What happened next is best expressed as a haiku poem:
Problems raise their hands.
You swing and miss. Try again.
Success! But how? Why?
She didn’t want to leave things alone like that, preferring to give the minimum required permission (and probably with an eye to writing a blog entry; I beat her to the punch, muhahahahaha!).
She removed successive permissions from the app pool identity account until … there was no longer any explicit permission for the app pool identity account at all. The web service continued to work just fine.
We went and rebooted the servers. Everything continued to work fine.
So, to recap: we gave the app pool identity full access and then took it away. The web service started working and never stopped working. Bizarre.
If anyone knows why that should have worked, please leave a comment.