As an example, when writing a console application against the SharePoint 2010 API you should be aware of some things.
I had a “rundown” with the OM today and since it was the first time from a console application I just did a “create new project…” in visual studio 2010.
By default VS chooses .NET 4.0 (32 bit) as target framework but as you know (I did too, I just had forgotten it), SP2010 runs .NET 3.5 (64 bit). VS runs in 32 bit and this is important because using the OM in SP2010 will not work if you don´t make some adjustments in the project file.
This is an example of that:
Have a look at this code that uses the SPUtility.GetGenericSetupPath to retrieve the path to the features folder.
As you can see the code returns null.
My first idea was of course that the SharePoint guys had forgotten to implement this in 2010 (sorry guys!).
As you can see from the screenshots below, the registry key indeed points to the 14 hive (or SharePointRoot as it is called nowadays).
No, the error in fact is that VS runs 32bit .NET 4.0 and a 32bit dll cannot open a 64bit dll (which Microsoft.SharePoint.dll is).
I knew this (they told us at SPC 2009), but I had just forgotten it.
Changing the target platform to Any CPU fixes this problem as you can see below.
And now the code runs perfectly.