12 April 2013

SPFarm.Local is null in SharePoint 2010 causing C# Console App to throw a “Object reference not set to an instance of an object” error

This one is one of the more annoying errors you’ll encounter in SharePoint development.  The simple reason for that is because the error you’re receiving is bogus.  I mean, sure it’s a “valid” error since the SPFarm.Local is actually null and you’re trying to reference it, but it doesn’t actually lead you anywhere.  As a SharePoint developer/admin/architect, you will often be faced with the need to iterate content in the farm.  Every good SharePoint developer knows that it all starts with the simple statement:

SPWebService svc = SPFarm.Local.Services.GetValue<SPWebService>(“”);

This should NEVER fail, unless you don’t actually have a SharePoint farm on your DEV box, but naturally you do, right? :-)  So then why would you ever see the below from your debugger window?




The problem stems from the architectural nature of SharePoint.  SharePoint as you know, has been purely x64 based since the 2010 version.  Add to that the fact that most utilities we write in the C# world to pull information from SharePoint, are Console apps, and you have the ingredients for our problem which is caused by Windows attempting to run a x86 based app under a x64 based architecture.  Now where this should normally work, it doesn’t in this case.  The real problem is that no architectural error is thrown.  The code simply returns null and does not work.  It can lead to many frustrating hours of debugging.

Since console apps are by their very nature x86 based, it’s very easy to make the mistake of compiling your console app to the x86 architecture.  If we go to the project properties for this console app, we'd find the following:




The “Platform target” is the setting we’re interested in.  By default Visual Studio 2010 will set this value to x86 for console apps.  It’s easy to forget to reset this value when quickly knocking out a console app.  Here’s how this should be set:




Once we make this simple change and press F5, we’ll be able to step past the problematic line of code and continue on our merry way.

Hopefully this article will save someone some time and frustration.



SharePoint Remote Event Receivers are DEAD!!!

 Well, the time has finally come.  It was evident when Microsoft started pushing everyone to WebHooks, but this FAQ and related announcement...