build.ps1 is the entry point script that wires everything together. It installs dependencies, configures the environment, and hands off to psake to run your actual build tasks. Think of it as the bootstrapper that gets a fresh machine — or a CI agent — from zero to a working build in a single command: .\build.ps1.
The default build.ps1 that ships with psake handles the basics well: bootstrap installation, help output, build environment detection, and proper CI exit codes. But once you're running concurrent CI jobs, managing internal package feeds, or onboarding new contributors, a few gaps start to show. Here are five patterns that harden your entry point for the real world.
The default script silently fails with cryptic "term not recognized" errors when dependencies aren't installed. A simple guard clause makes the fix obvious:
if (-not (Get-Module -Name 'PSDepend' -ListAvailable)) {
throw 'Missing dependencies. Please run with the "-Bootstrap" flag to install dependencies.'
}
Instead of hunting through stack traces, new contributors get a one-line message telling them exactly what to do.
Hardcoded [ValidateSet()] values require manual updates every time you add a task. Replace them with [ArgumentCompleter] for live discovery:
[ArgumentCompleter( {
param($Command, $Parameter, $WordToComplete, $CommandAst, $FakeBoundParams)
try {
Get-PSakeScriptTasks -BuildFile './build.psake.ps1' -ErrorAction 'Stop' |
Where-Object { $_.Name -like "$WordToComplete*" } |
Select-Object -ExpandProperty 'Name'
}
catch {
@()
}
})]
[string[]]$Task = 'default',
Now tab completion always reflects the actual tasks in your psake file — no maintenance required.
When parallel CI jobs share a module cache, Install-Module can hit file locks and fail. The fix: try importing existing modules first, and only install if the import fails.
$importSucceeded = $false
try {
Invoke-PSDepend @psDependParameters
$importSucceeded = $true
Write-Verbose 'Successfully imported existing modules.' -Verbose
}
catch {
Write-Verbose "Could not import all required modules: $_" -Verbose
Write-Verbose 'Attempting to install missing or outdated dependencies...' -Verbose
}
if (-not $importSucceeded) {
try {
Invoke-PSDepend @psDependParameters -Install
}
catch {
Write-Error "Failed to install and import required dependencies: $_"
throw
}
}
This eliminates a common source of flaky builds in enterprise CI pipelines.
Organizations often host modules on internal NuGet feeds (ProGet, Azure Artifacts, etc.). Idempotent registration keeps the script portable:
$repositoryName = 'internal-nuget-repo'
if (-not (Get-PSRepository -Name $repositoryName -ErrorAction 'SilentlyContinue')) {
Register-PSRepository @registerPSRepositorySplat
}
Pair this with TLS protocol patching to ensure compatibility with modern security requirements:
[System.Net.ServicePointManager]::SecurityProtocol = (
[System.Net.ServicePointManager]::SecurityProtocol -bor
[System.Net.SecurityProtocolType]::Tls12 -bor
[System.Net.SecurityProtocolType]::Tls13
)
PowerShellGet v3 introduces breaking API changes. Pinning to v2.x keeps behavior predictable:
$powerShellGetModuleParameters = @{
Name = 'PowerShellGet'
MinimumVersion = '2.0.0'
MaximumVersion = '2.99.99'
Force = $true
}
if (-not $powerShellGetModule) {
Install-Module @powerShellGetModuleParameters -Scope 'CurrentUser' -AllowClobber
}
Import-Module @powerShellGetModuleParameters
This prevents surprise breakage when a CI agent picks up a new PowerShellGet version.
These five patterns combine into a production-ready 143-line bootstrap that handles concurrent CI pipelines, enterprise package management, and mixed OS environments. For the full walkthrough and complete script, check out the original post on my blog.
]]>A core part of our mission with psake is meeting developers where they already work. Whether that's through AI-assisted workflows with Agent Skills, CI/CD pipelines, or your daily editor—we want psake to feel native to your environment. With VS Code being the editor of choice for so many PowerShell developers, a dedicated extension was a natural next step.
This isn't a minimal snippet pack. The v1.0 release is a full-featured integration that makes VS Code aware of your psake build system.
The extension automatically detects tasks from your psakefile.ps1 and surfaces them in VS Code's built-in task system. Your default task maps to the Build group, so Ctrl+Shift+B just works. Tasks refresh automatically when you save your build file—no manual reload needed.
A dedicated sidebar panel in the Explorer view gives you an at-a-glance view of every task in your project, complete with descriptions and dependency chains. Click any task to navigate directly to its definition, or hit the run button to execute it immediately.
Every Task declaration in your build file gets a "Run Task" CodeLens action. See a task, run it—right from the editor gutter. It's the fastest path from reading build logic to executing it.
If your project uses a wrapper script like build.ps1 (a common pattern in the psake ecosystem), the extension detects it automatically and routes task execution through it. This means your bootstrapping, dependency installation, and any custom setup all run correctly—just as they would from the terminal.
When you configure psake tasks in .vscode/tasks.json, the extension provides autocomplete for task names. Combined with the new "psake: Sync Tasks to tasks.json" command, you can quickly wire up your build tasks into VS Code's task runner with full IntelliSense support.
Scaffolding new tasks and build file structures is faster with nine built-in snippets covering everything from basic task definitions to Properties, Include, Framework, FormatTaskName, TaskSetup, and TaskTearDown blocks.
psakefile.ps1 or build.ps1That's it. No configuration required—but there's plenty available if you need it.
The extension works out of the box, but every aspect of its behavior can be tuned to fit your workflow. Toggle CodeLens on or off, point to a custom PowerShell executable, pass extra parameters to Invoke-psake or your build script, and customize shell arguments—all without restarting VS Code.
For the full list of settings, check out the VS Code extension docs.
The VS Code extension joins a growing set of tools designed to make psake easy to use wherever you are:
We're committed to making psake feel at home in every part of your development workflow. If you have ideas for where psake should go next, open an issue or join the conversation.
Give the extension a try and let us know what you think!
]]>If you've been looking for guidance on using PowerShellBuild to streamline your PowerShell module builds, you no longer need to piece things together from the README alone. The psake docs site now has a dedicated PowerShellBuild section covering:
$PSBPreference and how to customize every aspect of your buildThe headline feature in PowerShellBuild v0.8.0 is full Authenticode code-signing support for PowerShell modules. This was a highly requested capability, and it's now baked right into the standard build pipeline.
Get-PSBuildCertificate resolves a code-signing X509Certificate2 from five different sources:
Invoke-PSBuildModuleSigning signs your module files (.psd1, .psm1, .ps1) with Authenticode signatures. It supports configurable timestamp servers and hash algorithms including SHA256, SHA384, and SHA512.
New-PSBuildFileCatalog creates Windows catalog (.cat) files that record cryptographic hashes of your module's contents for tamper detection.
| Task | Description |
|---|---|
SignModule | Signs module files with Authenticode |
BuildCatalog | Creates a Windows catalog file |
SignCatalog | Signs the catalog file |
Sign | Meta-task that orchestrates the full signing pipeline |
These tasks slot into the existing build pipeline with proper dependency ordering: Build → SignModule → BuildCatalog → SignCatalog.
PowerShellBuild supports four ways to supply a certificate, listed here in order of common use:
1. Automatic (CI/CD) — Base64 PFX in an env var
# Store your PFX as a base64 secret (e.g. GitHub Actions secret SIGNCERTIFICATE)
# PowerShellBuild picks it up automatically when Sign.Enabled = $true
$PSBPreference.Sign.Enabled = $true
# CertificateSource defaults to 'Auto' — done
2. Local dev — certificate store
$PSBPreference.Sign.Enabled = $true
$PSBPreference.Sign.CertificateSource = 'Store'
# picks first valid, unexpired code-signing cert in Cert:\CurrentUser\My
# Or pin to a specific one by thumbprint:
$PSBPreference.Sign.CertificateSource = 'Thumbprint'
$PSBPreference.Sign.Thumbprint = 'AB12CD34EF...'
3. PFX file on disk
$PSBPreference.Sign.Enabled = $true
$PSBPreference.Sign.CertificateSource = 'PfxFile'
$PSBPreference.Sign.PfxFilePath = './codesign.pfx'
$PSBPreference.Sign.PfxFilePassword = (Read-Host -AsSecureString 'Password')
4. Pre-resolved object (Azure Key Vault, HSM, etc.)
# Get the cert however you like, then hand it directly:
$cert = Get-AzKeyVaultCertificate -VaultName 'MyVault' -Name 'CodeSignCert' |
Get-AzKeyVaultSecret | ... # your Key Vault retrieval logic
$PSBPreference.Sign.Enabled = $true
$PSBPreference.Sign.Certificate = $cert # bypasses CertificateSource entirely
All of these go in your Properties {} block (psake) or before dot-sourcing (Invoke-Build), before the task file is loaded. To also sign before publishing:
$PSBPublishDependency = @('Sign')
All signing operations include platform checks (Windows-only) with appropriate warnings, and verbose logging throughout makes troubleshooting straightforward.
Install-Module PowerShellBuild -RequiredVersion 0.8.0The psake Agent Skill is part of our growing collection of LLM tools designed to enhance how developers work with psake. Built on the open Agent Skills standard, it provides AI assistants with deep knowledge of psake patterns, syntax, and best practices. This portable format means the same skill works across different AI platforms—whether you're using Claude, GitHub Copilot, or other compatible AI tools.
The skill includes four comprehensive knowledge components:
SKILL.md – Core psake fundamentals covering command syntax, task definitions, dependencies, and troubleshooting patterns. This ensures your AI assistant understands the basics before diving into more complex scenarios.
PowerShell Modules Reference – Detailed guidance on using PowerShellBuild for module development workflows, including task patterns, build configurations, and testing integration.
Build Types Reference – Practical patterns for .NET, Node.js, and Docker builds, providing real-world examples for different project types.
Advanced Reference – Coverage of sophisticated topics like dynamic task generation, custom logging implementations, and CI/CD pipeline integration.
Once you've loaded the psake skill, your AI assistant can help with tasks like:
The psake Agent Skill works with multiple AI platforms thanks to the open Agent Skills standard.
psake.skill file from the releases sectionpsake.skill file from the repositoryThe same skill file works across both platforms, making it easy to maintain consistent AI assistance regardless of which tool you prefer.
By building on the Agent Skills open standard, we ensure that psake expertise is portable across AI platforms. As more tools adopt this standard, your investment in configuring the psake skill will continue to pay dividends across your entire development toolchain.
The psake-llm-tools repository is open source and welcomes community contributions. If you have patterns, examples, or improvements that would benefit other developers using psake with AI assistants, we'd love to see your pull requests.
Whether you're new to psake or a seasoned automation expert, the psake Agent Skill can help streamline your workflow and provide intelligent guidance when you need it most. Give it a try and let us know what you think!
Check out the project at github.com/psake/psake-llm-tools.
]]>Since launching this documentation site, we haven't been great about announcing new versions here. You could say we've been in stealth mode (though we're definitely not that cool).
Back in October, we released psake 4.9.1, and since then we've merged several pull requests, including some fantastic community contributions.
Check out the psake Changelog for all the details.
The next release will introduce a new way to override the psake logging mechanism. This will allow teams to integrate additional logging frameworks or create improved CI/CD-specific workflows.
Just a few days ago, we updated PowerShellBuild - our collection of common tasks for psake and Invoke-Build - to support overriding task dependencies. We also added localization support (more on that below). This brings us to version 0.7.3 as our latest release. Since version 0.6.2, we've seen 4.5k downloads, and we hope to keep improving the project based on your feedback.
See the PowerShellBuild Changelog for complete details.
You may have noticed them working on and reviewing code in our repositories, but we'd like to formally welcome Joshua Hendricks and Trent Blackburn as new members of the psake core team!
Joshua is our resident MVP who's well-known for presenting at PowerShell + DevOps Global Summit on building beautiful docs and sending notifications. He's a developer at Milestone Systems where he maintains their PowerShell module.
Trent currently develops PowerShell automations at Tesla, previously specialized in PowerShell at Amazon, and has also presented at the annual PowerShell + DevOps Global Summit.
Both bring incredible expertise to the team, and we're excited to have them aboard! If you're interested in contributing to psake, please consider opening an issue or submitting a pull request—we'd love to hear from you.
psake has long had the framework in place for supporting localization (l10n), but until now has only been available in English. One of our key goals is making psake as accessible as possible for users worldwide.
To make community contributions easier, we've set up a Crowdin project that enables straightforward translation requests and suggestions.
With the Crowdin project now live, we have a streamlined pipeline for introducing new localized versions. We'd love your help in making psake available in more languages - please consider contributing translations!
]]>This first iteration is composed of the original docs on the psake repository. I'll be slowly reviewing all the docs and updating them to make it easier for folks to get started.
In the near future, I'll be looking at more common CI/CD workflows and making sure we have good examples. Have suggestions? PR's are welcome!
]]>