When setting up a project on a fresh Windows machine or sharing a Visual Studio project across a team, post-build events that invoke PowerShell scripts often fail unexpectedly. The root cause is almost always Windows' default execution policy, which prevents arbitrary PowerShell scripts from running.

While your instinct might be to detect the execution policy in your batch script and display a warning, there is both a direct way to check the policy and a widely preferred best-practice solution that avoids bothering the developer altogether.

The Recommended Fix: Bypass Execution Policy per Command

Instead of requiring every developer or CI/CD runner to modify their machine-wide configuration with Set-ExecutionPolicy, you can bypass the policy solely for the scope of that single script execution. PowerShell provides the -ExecutionPolicy command-line switch specifically for this purpose.

powershell.exe -NoProfile -ExecutionPolicy Bypass -File "$(TargetDir)somefile.ps1"

Using -ExecutionPolicy Bypass:

  • Does not require local Administrator privileges.
  • Does not change the system-wide or user-wide registry settings.
  • Runs seamlessly in automated build pipelines (Azure DevOps, GitHub Actions, Jenkins).
  • Keeps the machine secure while allowing your build script to finish.

How to Query PowerShell Execution Policy from Batch

If your workflow strictly requires checking the current policy before deciding whether to proceed, you can capture the output of Get-ExecutionPolicy using a standard Batch FOR /F loop.

Batch Script Example

@echo off
setlocal enabledelayedexpansion

:: Capture the current PowerShell Execution Policy
for /f "usebackq delims=" %%i in (`powershell.exe -NoProfile -Command "Get-ExecutionPolicy"`) do (
    set "CURRENT_POLICY=%%i"
)

echo Current PowerShell Execution Policy is: !CURRENT_POLICY!

:: Check if the policy allows script execution
if /i "!CURRENT_POLICY!"=="Restricted" (
    goto :Blocked
) else if /i "!CURRENT_POLICY!"=="Undefined" (
    goto :Blocked
) else (
    goto :Allowed
)

:Blocked
echo [ERROR] PowerShell script execution is not enabled.
echo Please run: Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
exit /b 1

:Allowed
echo [INFO] Execution Policy allows running scripts. Executing script...
powershell.exe -NoProfile -File "C:\Users\username\file.ps1"
exit /b 0

Watch Out for 32-Bit vs. 64-Bit Policy Mismatches

If you are invoking batch scripts inside Visual Studio build events, keep in mind that older MSBuild processes or 32-bit build targets run inside a 32-bit context (SysWOW64). PowerShell execution policies can be configured independently for 32-bit and 64-bit environments.

To guarantee you are inspecting the native 64-bit PowerShell instance on a 64-bit OS, you can reference the path explicitly:

if exist "%SystemRoot%\sysnative\WindowsPowerShell\v1.0\powershell.exe" (
    set "PS_EXE=%SystemRoot%\sysnative\WindowsPowerShell\v1.0\powershell.exe"
) else (
    set "PS_EXE=powershell.exe"
)

%PS_EXE% -NoProfile -ExecutionPolicy Bypass -File "script.ps1"

Summary

While you can detect the policy using Get-ExecutionPolicy inside a FOR /F loop, the cleanest and most frictionless approach for Visual Studio post-build scripts is to pass -ExecutionPolicy Bypass directly into your powershell.exe call.