SPFarm.Local is null… what?

This comes from the "Captain Obvious" department, but took me a few minutes nonetheless. When running a utility application (which will probably be the next post), SPFarm.Local didn't throw any exceptions but simply returned as null.

A quick Google for "SPFarm null" brings you to the conclusion that this is a 64-bit problem. And indeed, I was trying to use a .NET application compiled in a 32-bit environment (under "Any CPU" target) on a 64-bit server. However, changing the target to 64-bit and recompiling did not fix the problem.

As it turns out, the account I was running it under didn't have permissions to access the farm. I would have expected SharePoint to throw some kind of UnauthorizedAccess exception, however in this scenario SPFarm.Local simply returns null. A quick "Run as..." and it came up fine, regardless of the target CPU.

Lesson learned - if you start seeing "Object reference not set to an instance of an object" exceptions with the SPFarm object, check the account permissions that you're running under.

  • Randy

    I ran into a similar problem. I have a 64bit Window Server 2003 virtual machine that I am running Unit Tests on SharePoint code within Visual Studio 2008. I can easily reference SPFarm on the 32bit environment, but the same code dies on 64. I am logged in as a Builtin administrator (the same as 32).

    Am I missing something?

    • Brandon

      I did notice that this occurs also when the account just doesn't have access to the farm. Try running your code with "Run as..." using the same account that the MOSS services are running under and see if that works.

  • Hi,

    I am still facing the problem of SPFarm.local is null. I am using WSS on Windows Server 2003. I have give all permissions to users but still getting the error on 64 bit OS.

    I am not getting what is missing now?

  • I am getting the same error any one have an idea on this.

  • If any one get answer for the above issue that would be great.

  • Max Dykhtiaruk

    Guys, I'm experiencing such problems from time to time and the root of it is - we store some settings in SPFarm.Local.Properties and one of the property is of one of our .Net type. After our product version is increased such properties (which referenced to old versions of our old .net classes) become unavailable. As a suggestion don't store custom types in SPFarm.Local.Properties in case when you have versioning, or at least make sure that they are removed during un-installation.

  • Have you ever considered writing an ebook or guest authoring on other sites?
    I have a blog based upon on the same subjects you discuss and would love to
    have you share some stories/information. I know
    my viewers would enjoy your work. If you are even remotely interested, feel free
    to shoot me an e-mail.