Next time you fire up PowerShell to work with the SharePoint API make sure you launch the proper bit version of PowerShell. Last week I had an interesting error that led to this blog post. Travel back in time a little bit with me to see where this 32 vs. 64 bit debate started.
Ever since the first pre-beta bits of Office 2010 landed in my lap I have been questioning whether it’s better to run 32 or 64 bit applications on a 64 bit host operating system. In relation to Office 2010 I heard a number of arguments for 32 bit including this link from the Office 2010 Engineering team. Given my typical usage scenarios 32 bit seemed the way to go since I wasn’t a “super RAM hungry” Excel user or the like.
Since I had chosen 32 bit Office 2010, I tried to stick with 32 bit version of other programs that I run assuming the same benefits and rules applied to other applications. This is where I was wrong. Last week I was attempting to use 32 bit PowerShell ISE (Integrated Scripting Environment) on a 64 bit WSS 3.0 server. When trying to reference the 64 bit SharePoint DLLs I got the following errors about not being able to find the web application.
I have run into these errors when I have hosts file issues or improper permissions to the farm / site collection but these were not the case. After taking a quick spin around the interwebs I ran across the below forum post comment and another MSDN forum reply that explained the error. Turns out that sometimes it’s not possible to run 32 bit applications against a 64 bit OS / farm / assembly / etc.
…the problem could also be because your SharePoint is 64-Bit but your app is running in 32-bit mode
I quickly exited 32 bit PowerShell ISE and ran the same code under 64 bit PowerShell ISE. All errors were gone and the script ran successfully.
The rules of 32 vs. 64 bit interoperability do not always apply evenly across all applications and scenarios. In my case I wasn’t able to run 32 bit PowerShell against 64 bit SharePoint DLLs. I’m updating all of my links and shortcuts to use 64 bit PowerShell where appropriate. I’m quite surprised it has taken me this long to run into this error, but sometimes blind luck is all that keeps you from running into errors. Lesson learned and hopefully this can benefit you as well. Happy SharePointing all!