Saturday, July 9, 2011

PowerShell 32 and 64 bit have different execution policy settings

I use PowerShell to automate many repetitive tasks. And build automation is one of the areas I like most.
I faced a stiuation when I get this error with a PowerShell script running in visual studio project post build event:
File XXX.ps1 cannot be loaded because the execution of scripts is disabled on this system. Please see "get-help about _signing" for more details.
I know this error is usually caused by an execution policy that denies execution of scripts. So I made sure the Execution Policy is set to RemoteSigned. But This did not work!!

I added this to the batch file that calls the PowerShell script:

powershell "Get-ExecutionPolicy -List"

And the result was:
Scope                         ExecutionPolicy

----- ---------------

MachinePolicy Undefined

UserPolicy Undefined

Process Undefined

CurrentUser Undefined

LocalMachine Undefined

After some research I found that since the machine is 64-bit, there were 2 versions of PowerShell, 32 and 64-bit. Again I edited the batch file adding :

Powershell.exe "Get-Variable PSHOME"

And ran a build from visual studio, the result was:

Name Value
---- -----
PSHOME C:\Windows\SysWOW64\WindowsPowerShell\v1.0

This shows that the version invoked was the 32-bit version, while the version I used to Set-ExecutionPolicy was the 64-bit version. I determined the paths from start menu shortcuts to Powershell:

Windows PowerShell (x86): %SystemRoot%\syswow64\WindowsPowerShell\v1.0\powershell.exe
And Windows PowerShell: %SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe

So I opened Windows PowerShell (x86) and executed:

Set-ExecutionPolicy RemoteSigned

And it worked.

So, did Visual Studio post build event call the 32-bit version because it's a 32-bit application?

1 comment:

Anonymous said...

Did I understand correctly that the 32-bit version of Powershell resides in [...]/syswow64/[...], whereas the 64-bit version lives in [...]/system32/[...]?! Yeah, that makes total sense. NOT! :)