Today I had to create a powershell script that make some changes to SharePoint as part of the post-build command line in Visual Studio. Long story short, I kept getting issues where the PowerShell shell I was invoking was unable to load the SharePoint powershell snap-in.
Now I knew that on 64bit Windows everything in the c:\windows\system32 directory was 64bit (despite the obvious naming error) and that everything in c:\windows\syswow64 was in fact the 32bit version of all the stuff in \system32 (again despite the obvious naming errors).
Note: These naming "errors" are part of the system to make it possible to run 32bit software on 64bit machines and to help out, Windows is automatically and quietly redirecting from one to the other as need be.
So when my post build command line looked something like: c:\windows\system32\WindowsPowerShell\v1.0\powershell.exe -Version 2 -file c:\myscript.ps1 because Visual Studio is only 32bit, when it launched powershell, Windows was actually secretly running the version in \syswow64 (the 32 bit PowerShell) which is unable to load 64bit PowerShell extensions (thus leading to a "The Windows PowerShell snap-in 'Microsoft.SharePoint.PowerShell' is not installed in this machine" message).
The answer? Disable folder redirection by using the "sysnative" alias which ensures the native (i.e. 64bit command always gets called).
c:\windows\sysnative\WindowsPowerShell\v1.0\powershell.exe -Version 2 -file c:\myscript.ps1
Thanks to the SharePoint Baker for blogging about the solution before me: http://www.thesharepointbaker.co.uk/2011/12/post-deployment-powershell-sharepoint-visual-studio/