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.

7 thoughts on “SPFarm.Local is null… what?

  1. 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?

    Reply
    1. Brandon Post author

      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.

      Reply
  2. Vijay Agarwal

    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?

    Reply
  3. 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.

    Reply
  4. cesitli Tarifler

    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.

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s