VsDevShell (Visual Studio Developer Shell)
Use this skill when you need to run Windows build tools that typically only work after a Visual Studio Developer Prompt /
has been applied.
When to use
Use this skill when you see errors like:
msbuild : The term 'msbuild' is not recognized...
- // not found
- CMake/Ninja can’t find the MSVC toolchain
Start with
, but the same approach applies to many VS toolchain commands.
Common tools that often need VS dev env
If you need to run any of the following, enter the VS dev shell first so PATH/Windows SDK/VC tools variables are set correctly:
- Build / project tooling: , ,
- Build systems (sometimes VS-bundled): ,
- Packaging & signing (Windows SDK): , , ,
- Resources & manifests (Windows SDK): , ,
- IDL / interop: , ,
- Binary inspection & PDB/symbol utilities (varies by installed components): , , , ,
- Driver/INF tooling (specialized; requires WDK components):
If the user’s command references one of these tools (or a build script calls them indirectly), run the “enter dev env” step before running the command.
Key idea
updates
process environment variables (PATH, INCLUDE, LIB, VSINSTALLDIR, etc.) for the
current PowerShell process.
- Run it in the same terminal/session where you will run .
- In VS Code tool runners, avoid starting a brand-new shell between “enter dev env” and “build”.
To restore the original environment (the values captured when you entered), use:
Important: one-time per PowerShell process
Treat
as a
one-time initialization step per PowerShell process:
- If you start a fresh / process (new terminal tab, new task invocation, new CI step, etc.) and you need VS build tools, you must call in that process.
- If you reuse an existing PowerShell process where you already called , don’t call it again.
- If you really need to re-enter without leaving, use .
- If you need a different dev environment (for example a different //), use a new PowerShell process and call there with the new parameters.
Prerequisite
This skill assumes the
module is installed and available on
.
- Verify availability:
Get-Module -ListAvailable VsDevShell
If it isn't present, install it from PowerShell Gallery for the current user:
Install-Module -Name VsDevShell -Repository PSGallery -Scope CurrentUser
Then import it:
Notes:
- On first install, PowerShell may prompt to install the NuGet provider and/or to trust .
Parameter mapping (intent → Enter-VsDevShell)
- : target architecture you want to build for
- : architecture of the machine running the tools
- Typical x64 Windows host →
- Typical x86 Windows host →
- Note: currently only / are accepted for .
- : accepted for compatibility, but currently not used to build arguments.
- : optional Windows SDK version string (only set when the user specifies a required SDK)
- , : optional switches to reduce startup work/noise
- : only set when targeting a specific Visual Studio installation
Recommended workflow (msbuild)
- Import and enter the environment (x64 host building x64):
- Run in the current PowerShell session:
Enter-VsDevShell -Arch x64 -HostArch x64 -NoLogo
- Verify:
-
Build:
- Run your command (solution/project + configuration/platform as requested).
VS Code / tool-runner tip
If your tool runner uses a fresh PowerShell process per command, run the “enter dev env” step and the build command in the same invocation, for example:
pwsh -NoProfile -Command "Import-Module VsDevShell; Enter-VsDevShell -Arch x64 -HostArch x64 -NoLogo; msbuild -version"
If your tool runner reuses a single long-lived terminal session, run
once at the start of that session, then run as many build commands as you need in the same session.
Cross-compile examples
-
Build Win32 from an x64 machine:
Enter-VsDevShell -Arch x86 -HostArch x64
-
Build ARM64 from an x64 machine:
Enter-VsDevShell -Arch arm64 -HostArch x64
Inspect without applying
If you want to see what would change without modifying your current process environment:
Get-VsDevEnv -Arch x64 -HostArch x64 | Format-Table -AutoSize
Cmdlets and common workflows
Enter / Leave
- Compute + apply VS dev environment:
Enter-VsDevShell -Arch x64 -HostArch x64
- Restore original values captured at enter time:
Export / Import
Export the computed delta to a standard
file (UTF-8 no BOM):
Export-VsDevEnv -Arch x64 -HostArch x64 -Path .\vsdev.env -Mode Update
Apply a
file in the current session:
- Pipeline form:
Import-VsDevEnv .\vsdev.env | Enter-VsDevShell
- Shortcut:
Enter-VsDevShell -EnvFilePath .\vsdev.env
Restore only the keys listed in the file (using the saved pre-enter snapshot):
Exit-VsDevShell -EnvFilePath .\vsdev.env
Fully piped chain (compute → export → import → apply):
powershell
Get-VsDevEnv -Arch x64 -HostArch x64 |
Export-VsDevEnv -Path .\vsdev.env -Mode Update -PassThru |
Import-VsDevEnv |
Enter-VsDevShell
Notes:
- This writes the computed values (including ) and will typically override whatever values your target process already has.
- Loading a dotenv file varies by tool/shell. For example, in you often need
set -a; source ./vsdev.env; set +a
to export the variables to child processes.
GitHub Actions ()
In GitHub Actions,
is a standard env file shared across steps.
Update it so later steps inherit the VS dev environment:
Export-VsDevEnv -Arch x64 -HostArch x64 -Path $env:GITHUB_ENV -Mode Update
If
is available and you want PATH handled there, use:
Export-VsDevEnv -Arch x64 -HostArch x64 -Path $env:GITHUB_ENV -Mode Update -PathMode GitHubPath
Apply it in the current step/session (optional):
Enter-VsDevShell -EnvFilePath $env:GITHUB_ENV
Notes
- Windows only (relies on and Visual Studio's ).
- If still isn’t available after enabling the environment, the installed Visual Studio workload may be missing MSBuild/VC tools.
- is currently accepted but not used to build arguments.