Solution: System.IO.FileNotFoundException on “SPSite = new SPSite(url)”

 

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. 

</end>

Technorati Tags:

11 thoughts on “Solution: System.IO.FileNotFoundException on “SPSite = new SPSite(url)”

  1. Fernando Gómez Flores

    Nice post, thanks. In my case, my problem was solved by changing the webservice’s apppool to match that of the sharepoint site collection.

    Cheers,
    Fernando A. Gómez F.

    Reply
  2. Wilson Edgar

    Hi, I also had the same problem. While developing on the same machine with sharepoint server, I was using Asp Development Server with different permission not certainly not running under the same identity as sharepoint (more about this here: http://msdn.microsoft.com/en-us/library/58wxa9w5(VS.80).aspx) so what, I’ve create a new site in IIS (port 8080) with the same identity as sharepoint.. and voila.
    Hope this helps

    Reply
  3. Zac Boyles
    There is a good chance that SQL’s securityadmin server role fixed the issue you were having once it was ran. That would be a good explanation for it continuing to work.
    Reply
  4. Faery

    Nice writeup.  We are having exactly the same issue right now.  This kind of problem and unexpected/unexplained behaviour is exactly why a lot of developers cannot stand working with SharePoint! 

    Reply
  5. Markus

    This part of the article….”gave the app pool identity account full access to SQL”, can you elaborate? “app pool identity” i presume means the app pool of the sharepoint site, but “full access to SQL”, how do you give that? Creating a login on the db server for the app pool identity i think isn’t quite enough…so is it on the sharepoint content db where the new login gets dbo (?) access? Or other sharepoint db’s as well, like the config db? For me that’s tough, because my sp content db apparently isn’t handled by sql server instance, apparently it’s under “/Microsoft Office Servers/14.0/Data”, anyway i don’t see it in sql server mgr….any ideas how i give “full access to SQL” in this case? Any reply would be appreciated…i’m kind stuck getting my console app to create an spsite object!!

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *