PowerShell Tip #1: Loading custom assemblies

PowerShell is a great trick to have in your bag, it allows easy and flexible scripting using SharePoint objects. Whether you're automating a certain one-off(ish) task, or just debugging a certain strange behaviour, it is always the tool I resort to.

This time, I was having an issue with an Event Receiver. PowerShell came to the rescue!
(...)

Visual Studio Tip #2: Run 64-bit version of PowerShell in Post-Build

Whether you are trying to achieve Continuous Integration, Automated Unit Testing or any other scenarios, it might be very beneficial to run PowerShell scripts automatically from Visual Studio after certain actions (such as Deploy or Build).

One problem I had was with the version of PowerShell that would be called from Visual Studio 2010: 32-bit or 64-bit. If you need to use SharePoint DLL's, you need to run the 64-bit version of PowerShell.

It won't work using "%WINDIR%\system32\ WindowsPowerShell \v1.0\powershell.exe", you'll get an error using the 64-bit DLLs, because the PowerShell console that is opened is the 32-bit version.

In order to call the 64-bit version of PowerShell, you must use this path: %WINDIR%\sysNative\WindowsPowerShell\v1.0\powershell.exe.