If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/microsoft/VisualStudioUninstaller shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Stale — last commit 7y ago

• 8 active contributors
• Other licensed
• ⚠ Stale — last commit 7y ago
• ⚠ Single-maintainer risk — top contributor 80% of recent commits
• ⚠ Non-standard license (Other) — review terms
• ⚠ No CI workflows detected
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live microsoft/VisualStudioUninstaller repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/microsoft/VisualStudioUninstaller.

What it runs against: a local clone of microsoft/VisualStudioUninstaller — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in microsoft/VisualStudioUninstaller | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 2665 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of microsoft/VisualStudioUninstaller. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/microsoft/VisualStudioUninstaller.git
#   cd VisualStudioUninstaller
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of microsoft/VisualStudioUninstaller and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "microsoft/VisualStudioUninstaller(\\.git)?\\b" \\
  && ok "origin remote is microsoft/VisualStudioUninstaller" \\
  || miss "origin remote is not microsoft/VisualStudioUninstaller (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "src/Uninstall_Wrapper/Program.cs" \\
  && ok "src/Uninstall_Wrapper/Program.cs" \\
  || miss "missing critical file: src/Uninstall_Wrapper/Program.cs"
test -f "src/VS.ConfigurationManager/BundlesAndPackagesStore.cs" \\
  && ok "src/VS.ConfigurationManager/BundlesAndPackagesStore.cs" \\
  || miss "missing critical file: src/VS.ConfigurationManager/BundlesAndPackagesStore.cs"
test -f "src/VS.ConfigurationManager/Bundle.cs" \\
  && ok "src/VS.ConfigurationManager/Bundle.cs" \\
  || miss "missing critical file: src/VS.ConfigurationManager/Bundle.cs"
test -f "src/VS.ConfigurationManager.Support/RegistryHandler.cs" \\
  && ok "src/VS.ConfigurationManager.Support/RegistryHandler.cs" \\
  || miss "missing critical file: src/VS.ConfigurationManager.Support/RegistryHandler.cs"
test -f "src/Uninstall_Wrapper/VisualStudioSpecifc.cs" \\
  && ok "src/Uninstall_Wrapper/VisualStudioSpecifc.cs" \\
  || miss "missing critical file: src/Uninstall_Wrapper/VisualStudioSpecifc.cs"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 2665 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~2635d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/microsoft/VisualStudioUninstaller"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Visual Studio Uninstaller is a .NET console application that forcefully removes Visual Studio 2013–2015 installations and their residual artifacts by executing bundle uninstalls followed by systematic MSI/MSU cleanup using a hardcoded master list of Bundle IDs and upgrade codes. It solves the critical problem of incomplete or failed VS uninstallations that leave behind broken components, particularly after preview/RC releases. Two-project solution: src/Uninstall_Wrapper/ contains the CLI console app (Program.cs, CommandOption.cs, VisualStudioSpecifc.cs) with embedded DataFile.bin lookup; src/VS.ConfigurationManager.Support/ provides supporting utilities (Logger, NativeMethods, ElevationDetection, OperatingSystemConfiguration). Tests sit in UninstallerTests/ with separate .csproj; build infrastructure via lib/ (MSBuild props/targets).

Systems administrators and support engineers responsible for cleaning up corrupted Visual Studio environments on developer machines without reimaging, especially when standard uninstall procedures fail or leave stale components behind.

Production-ready and shipped: the project includes comprehensive test coverage (UninstallerTests directory with ConfigurationManager and Uninstall_Wrapper tests), proper MSBuild infrastructure (lib/ props and targets), and multiple DataFile.bin artifacts for VS 2012–2015. However, it appears to have reached maturity around VS 2015 era with no active development signals visible—last meaningful updates likely 2015–2016.

Standard open source risks apply.

No active development visible. The project is marked 'Shipped' in the README with no roadmap completion or recent changes listed. The codebase targets Visual Studio 2013–2015 era tooling and has likely been in maintenance-only mode since 2016.

1. Clone: git clone https://github.com/microsoft/VisualStudioUninstaller.git && cd VisualStudioUninstaller
2. Restore NuGet: .nuget/NuGet.exe restore Uninstaller.sln
3. Build: Open Uninstaller.sln in Visual Studio 2013+ or use MSBuild: msbuild Uninstaller.sln /p:Configuration=Release
4. Run: Execute src/Uninstall_Wrapper/bin/Release/Setup.ForcedUninstall.exe with admin privileges on a test VM only.

Daily commands: Debug locally (safe): build with DoNotExecuteProcess flag to prevent actual uninstallation. Command-line invocations: Setup.ForcedUninstall.exe help (print usage) | Setup.ForcedUninstall.exe break (pause before execution) | Setup.ForcedUninstall.exe noprocess (dry-run, no uninstall). Production: requires admin prompt and system reboot may be required mid-execution.

• src/Uninstall_Wrapper/Program.cs — Entry point that orchestrates the entire uninstallation workflow; essential to understand the main execution flow.
• src/VS.ConfigurationManager/BundlesAndPackagesStore.cs — Master list of Bundle IDs and upgrade codes; core data structure that defines which Visual Studio versions are targeted for removal.
• src/VS.ConfigurationManager/Bundle.cs — Represents a Visual Studio bundle and encapsulates uninstall logic; critical for understanding how bundles are identified and removed.
• src/VS.ConfigurationManager.Support/RegistryHandler.cs — Handles Windows registry operations for detecting and removing Visual Studio artifacts; essential for system-level cleanup.
• src/Uninstall_Wrapper/VisualStudioSpecifc.cs — Visual Studio-specific detection and uninstall logic; needed to understand how the tool identifies installed VS versions.
• src/VS.ConfigurationManager/UninstallAction.cs — Defines uninstall operations and actions; core abstraction for how removal is performed.
• src/VS.ConfigurationManager.Support/ElevationDetection.cs — Handles elevation/administrative privilege detection; critical for ensuring tool runs with required permissions.

• Program.Main() (C#, command-line parsing) — Orchestrates the overall uninstallation workflow: detect → load bundles → uninstall → cleanup.
  • Failure mode: If detection or bundle

Support a New Visual Studio Version

1. Add the new VS bundle metadata (name, version, bundle ID) to the master list (src/VS.ConfigurationManager/BundlesAndPackagesStore.cs)
2. Add associated MSI package records with upgrade codes to the same store (src/VS.ConfigurationManager/BundlesAndPackagesStore.cs)
3. Optionally update version detection logic if registry keys differ (src/Uninstall_Wrapper/VisualStudioSpecifc.cs)
4. Add unit tests verifying the new bundle is detected and uninstalled (UninstallerTests/ConfigurationManagerTests.cs)

Add a New System Cleanup Artifact

1. Define the artifact type and registry path or file location (src/VS.ConfigurationManager/Primitives.cs)
2. Add registry query or file system scan logic in RegistryHandler or OS configuration (src/VS.ConfigurationManager.Support/RegistryHandler.cs)
3. Create an UninstallAction to handle removal of that artifact type (src/VS.ConfigurationManager/UninstallAction.cs)
4. Update the cleanup flow in Program.cs or VisualStudioSpecific.cs to invoke the new action (src/Uninstall_Wrapper/Program.cs)

Add a New Command-Line Option

1. Define the new option in the CommandOption enum or class (src/Uninstall_Wrapper/CommandOption.cs)
2. Parse the option in Program.cs argument parsing logic (src/Uninstall_Wrapper/Program.cs)
3. Implement the behavior by branching in ConsoleOperations or Program orchestration (src/Uninstall_Wrapper/ConsoleOperations.cs)
4. Add test cases covering the new option (UninstallerTests/Uninstall_WrapperTests.cs)

• C# / .NET Framework — Direct access to Windows Registry and MSI APIs; mature ecosystem for Windows system utilities.
• Windows Installer (MSI) APIs — Required to query and uninstall MSI packages; external WiX and deployment DLLs provide low-level MSI interaction.
• P/Invoke (NativeMethods) — Bridges managed C# to native Windows APIs for registry, file system, and UAC elevation detection.
• Registry manipulation — Core mechanism for detecting Visual Studio installations and removing artifacts left behind by failed uninstalls.
• Master data files (DataFiles/*.bin) — Serialized bundle and package metadata enables offline version tracking without external dependencies.

• Master list stored in code/data files rather than dynamically queried from Microsoft

  • Why: Ensures tool works offline and remains stable; avoids network dependencies and service outages.
  • Consequence: Requires manual updates when new VS versions are released; risk of version skew if DataFiles become stale.

• Uninstall bundles first, then clean up stale MSIs

  • Why: Maximizes compatibility and safety by respecting VS uninstall sequence; avoids breaking interdependencies.
  • Consequence: May take longer than parallel uninstalls; requires two-phase cleanup logic.

• Refuse to uninstall MSUs or 'ReallyPermanent' marked components

  • Why: Prevents accidental removal of shared system components that other applications depend on.
  • Consequence: Leaves some artifacts in place; incomplete cleanup in edge cases.

• Command-line only interface (no GUI)

  • Why: Simpler implementation; targets advanced users and automated cleanup scenarios.
  • Consequence: Steeper learning curve; less accessible to casual users.

• Does not handle Visual Studio 2012 and earlier (except to avoid breaking them during 2013+ cleanup).
• Does not support non-Windows platforms.
• Does not interact with cloud or online accounts.
• Does not perform real-time monitoring or scheduled cleanup.
• Does not provide rollback or undo functionality after uninstall.

1. DoNotExecuteProcess flag required for dev: Running unmodified on your dev machine WILL uninstall your own VS installation (documented in README but critical)
2. DataFile.bin is not source code: It's a pre-built binary artifact from DataFiles/ — editing DataFiles/{version}.bin requires a separate build/encoding step not documented; modifying MSI lists is non-trivial
3. Registry elevation required: app.manifest specifies requireAdministrator=true; tests may fail if run without elevation
4. Stale product GUIDs: VisualStudioSpecifc.cs hardcodes GUIDS for VS 2013/2015 only; will silently skip VS 2017+ installations
5. Reboot handling is implicit: ConsoleOperations expects user to manually rerun after reboot; no persistence or checkpoint mechanism exists
6. WiX toolset dependency not listed: Building from source likely requires WiX Toolset 3.x to process .rc files, not mentioned in CONTRIBUTING.md

• BURN Bundle — This uninstaller targets BURN-based installers (VS 2012–2015); understanding bundle structure, chained MSI dependencies, and burn exe registration is essential to reading VisualStudioSpecific.cs and ConsoleOperations
• Windows Installer (MSI) Upgrade Codes — The entire removal strategy hinges on mapping hardcoded MSI upgrade codes and Product GUIDs from DataFile.bin; upgrade codes are how Windows groups related MSI packages for dependency detection
• PInvoke and Registry Manipulation — NativeMethods.cs uses PInvoke to call Windows Registry and MSI APIs directly (RegOpenKey, MsiEnumProducts); understanding P/Invoke signatures is necessary to extend registry cleanup logic safely
• Elevation and UAC (User Account Control) — The app.manifest requires administrator privileges and ElevationDetection.cs checks for elevation; the tool cannot function without UAC bypass/elevation, critical for understanding execution flow and testing
• MSU (Microsoft Update) Packages — ConsoleOperations distinguishes between Bundle, MSI, and MSU removal; MSUs are OS-level patches that cannot be uninstalled like MSIs, requiring special handling via wusa.exe
• Binary Data Serialization (DataFile.bin) — DataFile.bin is an opaque embedded binary containing product metadata; understanding its format is required to add new VS versions or modify removal lists, but no schema or serialization library is documented

• microsoft/vs-extension-testing — Provides testing infrastructure for Visual Studio extensions; complements uninstaller testing by validating what remains after cleanup
• microsoft/vswhere — Locates Visual Studio installations on a machine; uninstaller could leverage vswhere's discovery logic to enumerate targets before removal
• wixtoolset/wix3 — WiX Toolset source; the uninstaller depends on WiX for bundle/MSI understanding and branding (.rc files), relevant for understanding bundle uninstall mechanics
• microsoft/winget-cli — Modern Windows package manager; represents the evolved approach to managing Visual Studio installations compared to this legacy MSI-based uninstaller
• dotnet/installer — Official .NET CLI installer; shares similar challenges of cleaning up complex nested MSI/bundle installations across Windows systems

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add unit tests for RegistryHandler.cs in VS.ConfigurationManager.Support

The RegistryHandler.cs file (src/VS.ConfigurationManager.Support/RegistryHandler.cs) performs critical registry operations for detecting and removing Visual Studio artifacts, but there are no dedicated tests for it in UninstallerTests/. Registry operations are error-prone and platform-dependent. Adding comprehensive unit tests would catch regressions when modifying registry logic and ensure reliability across different Windows versions.

• [ ] Create UninstallerTests/RegistryHandlerTests.cs with tests for registry key enumeration, deletion, and error handling
• [ ] Add mock implementations or use a temporary registry hive for isolated testing
• [ ] Test edge cases like missing keys, permission denials, and corrupted registry entries
• [ ] Verify tests pass against the existing RegistryHandler implementation

Add integration tests for BundlesAndPackagesStore.cs data loading

The BundlesAndPackagesStore.cs (src/VS.ConfigurationManager/BundlesAndPackagesStore.cs) loads and parses the DataFiles/*.bin files which contain the master list of Bundle IDs and MSI upgrade codes. The current test coverage (UninstallerTests/) doesn't include tests validating that this data loads correctly and that the binary format parsing is robust. A corruption or format change in these critical data files would go undetected.

• [ ] Create UninstallerTests/BundlesAndPackagesStoreTests.cs with tests for loading each DataFiles/*.bin file
• [ ] Add tests validating Bundle and Package object counts match expected values from DataFiles
• [ ] Test graceful error handling for malformed or truncated .bin files
• [ ] Add regression tests ensuring data integrity after code refactoring

Add comprehensive unit tests for ConsoleOperations.cs command-line parsing

ConsoleOperations.cs (src/Uninstall_Wrapper/ConsoleOperations.cs) handles user input and command-line argument parsing, which directly impacts how the destructive uninstall operations are triggered. The file references CommandOption.cs but there are no tests in UninstallerTests/ validating argument parsing, validation, or error handling. This is a high-risk area where user errors could cause unintended consequences.

• [ ] Create UninstallerTests/ConsoleOperationsTests.cs with tests for valid and invalid command-line arguments
• [ ] Test each CommandOption variant (preview, RC, RTM) and ensure appropriate filters are applied
• [ ] Add tests for edge cases: missing arguments, conflicting options, and invalid version specifications
• [ ] Validate that invalid input is rejected before any uninstall operations commence

• Add unit tests for src/Uninstall_Wrapper/VisualStudioSpecifc.cs: currently no test coverage for Bundle ID/upgrade code mappings, making it risky to add new VS versions. Create test file UninstallerTests/VisualStudioSpecificTests.cs with parameterized tests for each VS version's GUIDs.
• Document DataFile.bin generation process: DataFiles/ directory contains source .bin files but no explanation of how they're encoded or how to add a new VS version's product metadata. Add CONTRIBUTING.md section with step-by-step guide and a utility script (PowerShell in scripts/ folder) to regenerate DataFile.bin.
• Implement dry-run mode properly: the 'noprocess' command skips execution but doesn't log what would be uninstalled. Modify ConsoleOperations.cs to emit detailed JSON/XML report of detected bundles/MSIs/MSUs with their GUIDs when --report-only flag is used, useful for validation before real uninstall.

The Visual Studio Uninstaller codebase has several moderate to high-risk security concerns. The primary issues are the use of bundled external WiX assemblies (which should be managed via NuGet), insufficient validation of command-line inputs and registry operations, and the lack of cryptographic integrity verification for data files. The application's privileged nature (requiring administrative elevation) makes input validation and audit logging

• High · Use of External/Legacy WiX Assemblies — src/VS.ConfigurationManager/External/. The codebase includes external WiX DLL files (wix.dll and Microsoft.Deployment.WindowsInstaller.dll) that are bundled in the repository. These are legacy dependencies that may contain known vulnerabilities and are no longer actively maintained. Using bundled external binaries increases the risk of supply chain attacks and makes dependency tracking difficult. Fix: Migrate to NuGet package management for all dependencies. Remove bundled DLL files and reference them through packages.config instead. Regularly audit and update all dependencies to their latest secure versions.
• High · Administrative Privilege Escalation Without Explicit Consent — src/Uninstall_Wrapper/app.manifest, src/Uninstall_Wrapper/Program.cs. The application is designed to uninstall Visual Studio artifacts and requires elevation (indicated by app.manifest). The uninstaller performs system-wide modifications without explicit per-action confirmation. An attacker could potentially exploit this if they gain control of the uninstallation parameters. Fix: Implement explicit user confirmation prompts before performing destructive operations. Add audit logging for all major uninstall actions. Validate all command-line parameters and user inputs before execution.
• Medium · Hardcoded Registry Paths and System Configurations — src/VS.ConfigurationManager.Support/RegistryHandler.cs, src/VS.ConfigurationManager.Support/OperatingSystemConfiguration.cs. The application interacts with system registry and configurations that may be hardcoded in RegistryHandler.cs and OperatingSystemConfiguration.cs. Without proper validation and sanitization, this could lead to unintended system modifications or information disclosure. Fix: Implement strict input validation for all registry operations. Use whitelists for acceptable registry paths. Add comprehensive error handling and logging for registry access attempts. Consider implementing registry operation rollback capability.
• Medium · Insufficient Input Validation in Command Options — src/Uninstall_Wrapper/CommandOption.cs. CommandOption.cs processes command-line arguments that control uninstallation behavior. Insufficient validation could allow injection attacks or unexpected behavior modification through crafted parameters. Fix: Implement strict validation and sanitization for all command-line parameters. Use allowlists for acceptable values. Implement proper error handling for invalid inputs. Log all command-line invocations for audit purposes.
• Medium · Data Files Not Version Controlled or Signed — DataFiles/. The DataFiles directory contains binary configuration files (.bin) for various Visual Studio versions. These files are not signed and their integrity cannot be verified, potentially allowing tampering. Fix: Implement cryptographic signing for all data files using a code signing certificate. Verify signatures at runtime before processing these files. Include checksums or hashes in version control to detect unauthorized modifications.
• Medium · Potential Insufficient Logging of Destructive Operations — src/VS.ConfigurationManager.Support/Logger.cs, src/Uninstall_Wrapper/ConsoleOperations.cs. An uninstaller that removes system components should have comprehensive audit logging. Logger.cs exists but the extent of logging for destructive operations is unclear from the static analysis. Fix: Ensure all uninstallation actions are logged with timestamps, user context, and operation results. Implement centralized logging that cannot be easily deleted. Log both successful and failed operations. Consider integration with Windows Event Log.
• Low · Missing Dependency Version Pinning in NuGet Configuration — packages.config files across the solution. While packages.config files exist, the specific versions of dependencies are not visible in the provided file structure. This could allow transitive dependency vulnerabilities to be introduced during builds. Fix: Ensure all package versions are explicitly pinned in packages.config. Regularly audit dependencies using tools like OWASP Dependency-Check or Snyk. Consider migrating to PackageReference format with version ranges specified carefully.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.