MVH

Appearance

PowerShell Script Packager ​

Converts PowerShell scripts into standalone Windows executables with automatic versioning using PS2EXE.

The Problem ​

Distributing PowerShell scripts as .ps1 files creates real usability problems. You can't right-click and "Run as Administrator" on a script file like you can with an executable. For end users unfamiliar with PowerShell, distributing scripts in this way is just painful.

Converting scripts to standalone executables solves these problems. PS2EXE compiles PowerShell scripts into .NET executables that run on any Windows system without requiring PowerShell to be installed. But setting up the build process aka PS2EXE installation, version management, artifact handling, and release workflows, is repetitive across projects.

The Solution ​

This action automates PowerShell-to-EXE conversion with integrated versioning. It uses PS2EXE to compile your script into a standalone Windows executable, embeds the version in the filename via GitVersion, and uploads it as a workflow artifact.

Push your PowerShell code, get a versioned executable ready for distribution.

Key Capabilities ​

  • Script compilation: Converts PowerShell scripts to .NET executables via PS2EXE
  • Automatic versioning: GitVersion embeds semantic versions in executable filenames
  • Artifact management: Uploads executables as workflow artifacts automatically
  • True standalone binaries: Executables run on any Windows system without PowerShell installed

Quick Example ​

yaml
- name: Package script
  uses: michielvha/package-pwsh-script-action@v1
  with:
    name: 'MyScript'
    script-path: 'pwsh/scripts/main.ps1'
    config-file: 'gitversion.yml'

The action produces MyScript-{version}.exe ready for distribution.

Why This Matters ​

PowerShell is powerful for automation, especially when you are stuck in the microsoft ecosystem, but distributing scripts can be painful. Executables eliminate the friction. Double-click to run, no PowerShell knowledge required, no execution policy hassles.

Version embedding in the filename makes support easier. When users report issues, they can tell you exactly which version they're running. No more "I downloaded it last month" conversations.

This is particularly useful for internal tooling. Build utilities, deployment scripts, or admin tools as PowerShell, then distribute them as executables. IT staff or end users can run them without understanding PowerShell.

For detailed usage, configuration options, and PS2EXE customization, see the GitHub repository.