Infra, Ops & WorkflowSûr100100/100

Deploy Msbuild To Vs (.NET)

Deploy locally-built MSBuild binaries into a Visual Studio installation for testing and debugging. Use when you need VS itself to use your local MSBuild changes, or when debugging MSBuild as invoked by VS.

ou envoie-le directement à ton agent.

Installer dans ton projet

$ curl -fsSL https://arboristhree.xyz/cli/install-skill.mjs -o /tmp/arboris-install-skill.mjs && node /tmp/arboris-install-skill.mjs deploy-msbuild-to-vs__dotnet-dotnet__src-msbuild-github-skills-fdac55e77830
.NET
dotnet/dotnet
Contenu à copier
---
name: deploy-msbuild-to-vs
description: Deploy locally-built MSBuild binaries into a Visual Studio installation for testing and debugging. Use when you need VS itself to use your local MSBuild changes, or when debugging MSBuild as invoked by VS.
argument-hint: Deploy local MSBuild to VS, patch VS with built MSBuild, debug MSBuild inside VS.
metadata:
  origin: .NET
---

# Deploying Built MSBuild into Visual Studio

This skill guides you through replacing Visual Studio's bundled MSBuild with your locally-built binaries, so that builds initiated from within VS use your changes. It also covers debugging MSBuild when invoked by VS and restoring the original state.

## When to Use

- You need Visual Studio's build (Ctrl+Shift+B, Build Solution, design-time builds) to use your local MSBuild changes.
- You are debugging an issue that only reproduces when MSBuild is called through the VS process (`devenv.exe`).
- You want to test MSBuild changes against a real VS solution end-to-end.

**If you only need command-line testing**, prefer the bootstrap approach instead (see the `use-bootstrap-msbuild` skill). It is faster and does not risk breaking your VS installation.

## Prerequisites

- Windows (the deploy script targets VS on Windows).
- Visual Studio installed (2022 or later, including 2026 and preview versions).
- An **administrator** PowerShell prompt (required to write into `Program Files`).
- The MSBuild repo cloned and buildable.

## Step 1: Build MSBuild

Run a full build from the repo root to produce the bootstrap output:

```powershell
.\build.cmd
```

By default this builds `Debug` configuration. If you want `Release`:

```powershell
.\build.cmd /p:Configuration=Release
```

The build creates bootstrap binaries under `artifacts\bin\MSBuild.Bootstrap\{configuration}\`.

## Step 2: Locate Your VS MSBuild Bin Folder

Find the MSBuild `Bin` folder inside your VS installation. The path depends on your VS version and edition.

**⚠ Important**: If you have multiple VS versions or editions installed side-by-side, make sure you identify the correct installation path for the instance you want to patch. Confirm the path exists before deploying.

The general pattern is:

```text
C:\Program Files\Microsoft Visual Studio\{version}\{edition}\MSBuild\Current\Bin
```

Where `{version}` is the year (e.g. `2022`, `2026`) or a numeric version for previews (e.g. `18`), and `{edition}` is `Enterprise`, `Professional`, `Community`, or `Preview`.

Example paths:

| VS Version | Edition | Typical Path |
| ---------- | ------- | ------------ |
| 2026 | Enterprise | `C:\Program Files\Microsoft Visual Studio\2026\Enterprise\MSBuild\Current\Bin` |
| 2022 | Community | `C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Current\Bin` |
| Preview (v18) | Preview | `C:\Program Files\Microsoft Visual Studio\18\Preview\MSBuild\Current\Bin` |

### Finding the path automatically

The most reliable way to locate your VS installation is with `vswhere`:

```powershell
# List all VS installations with their paths
& "${env:ProgramFiles(x86)}\Microsoft Visual Studio\Installer\vswhere.exe" -all -format table

# Get the MSBuild Bin path for the latest installation
$vsPath = & "${env:ProgramFiles(x86)}\Microsoft Visual Studio\Installer\vswhere.exe" -latest -property installationPath
"$vsPath\MSBuild\Current\Bin"
```

Alternatively, from a VS Developer Command Prompt:

```cmd
where msbuild
```

Use the directory containing that `MSBuild.exe`.

## Step 3: Deploy with the Script

From an **administrator** PowerShell, run:

```powershell
.\scripts\Deploy-MSBuild.ps1 -destination "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Bin"
```

### Script Parameters

| Parameter | Default | Description |
| --------- | ------- | ----------- |
| `-destination` | *(required)* | The VS MSBuild `Bin` folder path |
| `-configuration` | `Debug` | Must match the configuration used in `build.cmd` |
| `-runtime` | `Detect` | Auto-detects `Desktop` vs `Core` from the path. Use `Desktop` for VS, `Core` for .NET SDK |
| `-binDirectory` | `artifacts\bin` | Override if build output is elsewhere |
| `-makeBackup` | `$true` | Creates a timestamped `Backup-*` folder before overwriting |

### What Gets Copied

The script copies from `artifacts\bin\MSBuild.Bootstrap\{configuration}\net472\`:

- **Core DLLs**: `Microsoft.Build.dll`, `Microsoft.Build.Framework.dll`, `Microsoft.Build.Tasks.Core.dll`, `Microsoft.Build.Utilities.Core.dll`, `Microsoft.NET.StringTools.dll`
- **Targets files**: `Microsoft.Common.targets`, `Microsoft.CSharp.targets`, `Microsoft.VisualBasic.targets`, and many more
- **Executables**: `MSBuild.exe` (x86 and amd64), `MSBuildTaskHost.exe`
- **Framework dependencies**: Various `System.*` assemblies needed for .NET Framework

## Step 4: Test in Visual Studio

1. **Close and reopen** Visual Studio (it caches MSBuild on startup).
2. Open a solution and build — VS now uses your locally-built MSBuild.
3. Verify by checking the build output or binary log for your changes.

## Restoring the Original MSBuild

The deploy script creates a backup folder at `{destination}\Backup-{timestamp}\` by default.

To restore:

```powershell
# Find the backup folder
Get-ChildItem "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Bin\Backup-*"

# Copy everything back
Copy-Item "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Bin\Backup-{timestamp}\*" `
          "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Bin\" -Recurse -Force
```

Alternatively, run **Visual Studio Installer → Modify → Repair** to fully restore the original binaries.

⚠ **CAUTION**: If you overwrite MSBuild in Visual Studio and something goes wrong, VS itself may break (since VS uses MSBuild internally). Always keep the backup and know how to restore before deploying.

## Debugging MSBuild Inside Visual Studio

When MSBuild is invoked by VS (for real builds or design-time builds), you can attach a debugger using environment variables. Set these **before** launching VS:

### Breakpoint at BuildManager.BeginBuild (Recommended for VS)

```powershell
$env:MSBuildDebugBuildManagerOnStart = "1"   # 1 = Debugger.Launch(), 2 = wait for attach
$env:MSBuildDebugProcessName = "devenv"      # Only trigger in the VS process
devenv.exe
```

This breaks into `BuildManager.BeginBuild`, which is where VS calls into MSBuild's API.

### Breakpoint at MSBuild Entry Point

```powershell
$env:MSBUILDDEBUGONSTART = "1"   # 1 = Launch debugger, 2 = Wait for attach, 3 = Main process only
devenv.exe
```

### Capturing Full Binary Logs from VS

VS heavily filters MSBuild events and suppresses them entirely during design-time builds. To capture everything:

```powershell
$env:MSBuildDebugEngine = "1"
$env:MSBUILDDEBUGPATH = "C:\temp\MSBuild_Logs"   # Optional: override log output directory
$env:MSBuildDebugProcessName = "devenv"            # Optional: only log from VS
devenv.exe
```

This injects a binary log at `BuildManager.BeginBuild`, capturing full logs for both real and design-time builds. Logs are saved to `MSBuild_Logs\` under the current directory (or `MSBUILDDEBUGPATH` if set).

## Deploying to .NET SDK Instead

To patch a .NET SDK installation rather than VS:

```powershell
.\scripts\Deploy-MSBuild.ps1 -destination "C:\Program Files\dotnet\sdk\10.0.100" -runtime Core
```

The script auto-detects SDK paths (containing `dotnet` and `sdk`), but you can force it with `-runtime Core`.

## Cross-Machine Deployment

If you cannot build MSBuild on the target machine:

1. Build and deploy to an **empty folder**:

   ```powershell
   .\scripts\Deploy-MSBuild.ps1 -destination "C:\temp\msbuild-deploy"
   ```

2. Copy the contents of that folder to the target machine's VS MSBuild Bin folder.
3. Make a manual backup of the target machine's files first.

## Troubleshooting

| Problem | Solution |
| ------- | -------- |
| Access denied when deploying | Run PowerShell as **Administrator** |
| VS won't start after deploy | Restore from `Backup-*` folder or run VS Installer Repair |
| Changes not reflected in VS | Close all VS instances and reopen; kill lingering `MSBuild.exe` processes |
| Configuration mismatch | Ensure `-configuration` matches what you passed to `build.cmd` |
| Build errors in MSBuild repo | Run `.\build.cmd` from a clean state; see [Something's wrong in my build](https://github.com/dotnet/msbuild/blob/main/documentation/wiki/Something's-wrong-in-my-build.md) |

## Quick Reference

| Step | Command |
| ---- | ------- |
| Build MSBuild | `.\build.cmd` |
| Deploy to VS (admin) | `.\scripts\Deploy-MSBuild.ps1 -destination "{VS MSBuild Bin path}"` |
| Deploy Release build | `.\scripts\Deploy-MSBuild.ps1 -destination "{path}" -configuration Release` |
| Debug MSBuild in VS | Set `$env:MSBuildDebugBuildManagerOnStart = "1"` then launch `devenv.exe` |
| Capture VS binlogs | Set `$env:MSBuildDebugEngine = "1"` then launch `devenv.exe` |
| Restore original | Copy back from `Backup-*` folder or run VS Installer Repair |

## See Also

- [Deploy-MSBuild documentation](https://github.com/dotnet/msbuild/blob/main/documentation/Deploy-MSBuild.md)
- [Building and Debugging on Full Framework](https://github.com/dotnet/msbuild/blob/main/documentation/wiki/Building-Testing-and-Debugging-on-Full-Framework-MSBuild.md)
- [Bootstrap Documentation](https://github.com/dotnet/msbuild/blob/main/documentation/wiki/Bootstrap.md)
Colle ce Markdown dans ton agent ou utilise les boutons ci-dessus pour l’écrire dans ton projet.

Ce que fait Deploy Msbuild To Vs (.NET)

You need Visual Studio's build (Ctrl+Shift+B, Build Solution, design-time builds) to use your local MSBuild changes.
You are debugging an issue that only reproduces when MSBuild is called through the VS process (`devenv.exe`).
You want to test MSBuild changes against a real VS solution end-to-end.
Windows (the deploy script targets VS on Windows).

Comment utiliser Deploy Msbuild To Vs (.NET)

1
Copie le prompt
Un clic copie le prompt packagé (ou l'envoie à ton agent).
2
L'agent installe le skill
Il ajoute le SKILL.md et ses ressources à ton projet.
3
Activation automatique
Le skill s'active dès que le contexte correspond.

Déclencheurs pour Deploy Msbuild To Vs (.NET)

Dis simplement à ton agent quelque chose comme :

Applique le skill deploy-msbuild-to-vs__dotnet-dotnet__src-msbuild-github-skills-fdac55e77830 à cette tâche
Utilise deploy-msbuild-to-vs__dotnet-dotnet__src-msbuild-github-skills-fdac55e77830 pour améliorer cette implémentation
Passe en revue ce sujet avec deploy-msbuild-to-vs__dotnet-dotnet__src-msbuild-github-skills-fdac55e77830

Skills liés à Deploy Msbuild To Vs (.NET)

Add CLI Command (.NET)
Add or change a dotnet CLI command, subcommand, or option across the relevant CLI projects. USE FOR: adding or changing a dotnet CLI command/subcommand, adding a new Option<T> or Argument<T>, registering a subcommand in the command tree, changing an option's help description or a command's runtime message, wiring a command parser, or updating --help output.
Add Dotnet Aot Command (.NET)
Add, enable, or review a dotnet CLI command or feature in the Native AOT CLI (src/Cli/dotnet-aot) and prove its compatibility. USE FOR: migrating a command or option to AOT, reviewing an AOT migration PR, defining conservative eligibility and managed fallback, changing AotSourceFiles.props or AotDependencies.props, validating AOT/managed parity, NativeAOT-publishing tests, checking binary-size impact, or using the dn harness and separated SDK layout. DO NOT USE FOR: resolving IL trim/AOT analyzer warnings alone (use dotnet-aot-compat), running dotnet.Tests incrementally (use incremental-test), or pure managed CLI work.
Add Net Analyzer (.NET)
Add, port, or change a .NET code analysis rule (CA####) under src/Microsoft.CodeAnalysis.NetAnalyzers. USE FOR: implementing a new CA analyzer and its code fixer, porting a rule or PR from the retired dotnet/roslyn-analyzers repo, allocating a diagnostic ID from DiagnosticCategoryAndIdRanges.txt, choosing RuleLevel/severity/category, wiring resx + xlf strings, recording the rule in AnalyzerReleases.Unshipped.md, regenerating the analyzer documentation/sarif files, and writing MSTest analyzer/code-fix tests with the VerifyCS/VerifyVB harness. DO NOT USE FOR: NETSDK#### MSBuild diagnostics (src/Tasks), CS####/BC#### compiler diagnostics or IDE#### analyzers (dotnet/roslyn), or CONTAINER#### diagnostics (src/Containers).