## Summary of the Pull Request Adds a `PowerRename.UITests.Next` suite powered by winappcli and automates all 18 scenarios from #40663. The suite covers PowerRename settings, search and replace behavior, regular expressions, formatting and filtering options, file-list interactions, and both classic and Windows 11 context-menu workflows. The PR also stabilizes shared `UITestAutomation.Next` runner lifetimes and settings restoration, adds automation IDs for the original and renamed counters, and prepares unsigned CI builds for PowerRename shell testing. CI now signs the sparse context-menu MSIX and the runner/Settings IPC companions with a disposable machine-trusted test identity. ## PR Checklist - [x] Closes: #40663 - [x] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [x] **Tests:** Added/updated and all pass - [x] **Localization:** All end-user-facing strings can be localized - [x] **Dev docs:** Added/updated - [x] **New binaries:** Not applicable; no new shipped product binaries are added - [x] JSON for signing: Not applicable - [x] WXS for installer: Not applicable - [x] YML for CI pipeline: The new UI-test project is discovered through the existing `*UITest*.csproj` pipeline flow and is registered in `PowerToys.slnx` - [x] YML for signed pipeline: Not applicable - [x] **Documentation updated:** Not applicable; there are no user-facing behavior or documentation changes ## Detailed Description of the Pull Request / Additional comments ### PowerRename UI tests - Adds a 25-case `PowerRename.UITests.Next` executable covering all 18 checklist items from #40663. - Exercises classic context-menu registration on Windows 10 and Windows 11. - Exercises the signed Windows 11 tier-1 context menu, including icon visibility and real invocation with an Explorer selection. - Covers search/replace preview and application, text formatting, file/folder/subfolder inclusion, filename/extension scope, enumeration, case sensitivity, match-all behavior, regular expressions, file timestamps, Boost syntax, MRU autocomplete, persisted values, and file-list selection/filtering. - Preserves the existing legacy tests. ### Test reliability and automation hooks - Reuses one runner/Settings lifetime across the complete PowerRename suite to avoid repeated cold launches on constrained agents. - Retains and restores global settings for the full class lifetime and verifies that both Settings and the runner remain healthy. - Propagates scope and PowerRename cleanup failures instead of silently leaking process or profile state. - Adds `OriginalCount` and `RenamedCount` automation IDs. These are automation-only metadata and do not change the visible UI. - Uses stable preview samples, exact count targeting, authoritative Explorer selection, readable classic-menu inventories, and live UIA visibility for popup items. ### Unsigned CI build support - Extends the existing sparse-package test signer with required Authenticode companion files. - PowerRename jobs sign `PowerToys.exe` and `PowerToys.Settings.exe` with the same disposable machine-trusted test identity used for sparse MSIX packages. - This preserves Release IPC authentication while allowing Settings module-toggle commands to work on unsigned PR builds. - Windows 11 and ARM64 PowerRename jobs require a validly signed `PowerRenameContextMenuPackage.msix` before tests start. ## Validation Steps Performed ### Builds and discovery - `PowerRename.UITests.Next` Debug x64 build: passed - `PowerRename.UITests.Next` Debug ARM64 cross-build: passed - `PowerRenameUI` Release x64 build: passed - `UITestAutomation.Next.UnitTests` Debug x64 build: passed - `UITestAutomation.Next.UnitTests`: 16/16 passed - Microsoft.Testing.Platform discovery: 25 unique PowerRename test cases ### Local VM matrix All runs used the complete unfiltered `TestCategory=PowerRename` suite and restored the standard user's settings file byte-for-byte. | Guest | Profile | Result | |---|---|---:| | Windows 10 x64 | Default, 4 vCPU / 8 GB | 25/25 | | Windows 10 x64 | Constrained, 1 vCPU / 4 GB | 25/25 | | Windows 11 x64 | Default, 4 vCPU / 8 GB | 25/25 | | Windows 11 x64 | Constrained, 1 vCPU / 4 GB | 25/25 | ### Azure DevOps UI Test Automation - Final build: [155646235 / 20260824.1](https://dev.azure.com/microsoft/Dart/_build/results?buildId=155646235) - Source revision: `4496683104aea622b30179909bd6e95a17d5500f` - ARM64: 25/25 passed - Windows 10 x64: 25/25 passed - Windows 11 x64: 25/25 passed - Total: 75/75 passed, with zero failed, skipped, not-executed, or unanalyzed results - ARM64 and x64 Release product builds succeeded and published their normal artifacts - Signing steps verified the PowerRename sparse MSIX where applicable and both IPC companion executables on every PowerRename test job <img width="372" height="314" alt="image" src="https://github.com/user-attachments/assets/bc303673-0325-4f85-8d70-ef93110baf5b" />
PowerToys Developer Documentation
Welcome to the PowerToys developer documentation. This documentation provides information for developers who want to contribute to PowerToys or understand how it works.
Getting Started
Prerequisites
- Windows 10 April 2018 Update (version 1803) or newer
- Visual Studio 2026 (recommended) or Visual Studio 2022 17.4+ with the following workloads/components:
- Desktop Development with C++
- WinUI application development
- .NET desktop development
- Windows 11 SDK (10.0.22621.0)
- Windows 11 SDK (10.0.26100.3916)
- .NET 8 SDK
- Enable long paths in Windows (see Enable Long Paths for details)
Tip: You can install Visual Studio with all required workloads automatically using the WinGet configuration files in the repository:
winget configure .config\configuration.wingetPick the file that matches your VS edition (e.g.,
configuration.vsProfessional.wingetorconfiguration.vsEnterprise.winget).
Fork, Clone, and Set Up
- Fork the repo on GitHub if you haven't already
- Clone your fork locally
- Run the automated setup script (recommended):
.\tools\build\setup-dev-environment.ps1
This script will:
- Enable Windows long path support (requires administrator privileges)
- Enable Windows Developer Mode (requires administrator privileges)
- Guide you through installing required Visual Studio components from
.vsconfig - Initialize git submodules
Run with -Help to see all available options.
Manual setup (if you prefer not to use the script)
Install Visual Studio dependencies
- Open the
PowerToys.slnxfile. - If you see a dialog that says
install extra componentsin the solution explorer pane, clickinstall
Alternatively, import the .vsconfig file from the repository root using Visual Studio Installer to install all required workloads.
Initialize submodules
This is a one-time step required before you can compile most parts of PowerToys.
- Open a terminal
- Navigate to the folder you cloned PowerToys to.
- Run
git submodule update --init --recursive
Building
Using Visual Studio
- Open
PowerToys.slnxin Visual Studio. - In the
Solutions Configurationdrop-down menu selectReleaseorDebug. - From the
Buildmenu chooseBuild Solution, or press Control+Shift+b on your keyboard. - The build process may take several minutes depending on your computer's performance. Once it completes, the PowerToys binaries will be in your repo under
x64\Release\.- You can run
x64\Release\PowerToys.exedirectly without installing PowerToys, but some modules (i.e. PowerRename, ImageResizer, File Explorer extension etc.) will not be available unless you also build the installer and install PowerToys.
- You can run
Using Command Line
You can also build from the command line using the provided scripts in tools\build\:
# Build the full solution (auto-detects platform)
.\tools\build\build.ps1
# Build with specific configuration
.\tools\build\build.ps1 -Platform x64 -Configuration Release
# Build only essential projects (runner + settings) for faster iteration
.\tools\build\build-essentials.ps1
# Build everything including the installer (Release only)
.\tools\build\build-installer.ps1
Debugging
See Debugging for detailed debugging techniques, including Visual Studio setup, attaching to child processes, and troubleshooting build errors.
Creating a New PowerToy
See Creating a New PowerToy for an end-to-end guide covering module architecture, settings integration, installer packaging, and testing.
Building Command Palette Extensions
If you want to build your own extensions for Command Palette, check out the Command Palette extensibility documentation. It covers how to create, package, and distribute custom extensions that integrate with Command Palette.
Development Guidelines
- Coding Guidelines - Development guidelines and best practices
- Coding Style - Code formatting and style conventions
- Logging and Telemetry - How to use logging and telemetry
- Localization - How to support multiple languages
- UI Testing - How to write UI tests for PowerToys
- Developing with VS Code - Build, debug, and contribute using VS Code
Rules
- Follow the pattern of what you already see in the code.
- Coding style.
- Try to package new functionality/components into libraries that have nicely defined interfaces.
- Package new functionality into classes or refactor existing functionality into a class as you extend the code.
- When adding new classes/methods/changing existing code, add new unit tests or update the existing tests.
GitHub Workflow
- Before starting to work on a fix/feature, make sure there is an open issue to track the work.
- Add the
In progresslabel to the issue, if not already present. Also add aCost-Small/Medium/Largeestimate and make sure all appropriate labels are set. - If you are a community contributor, you will not be able to add labels to the issue; in that case just add a comment saying that you have started work on the issue and try to give an estimate for the delivery date.
- If the work item has a medium/large cost, using the markdown task list, list each sub item and update the list with a check mark after completing each sub item.
- Before opening a PR, ensure your changes build successfully locally and functionality tests pass. This is especially important for AI-assisted (vibe coding) contributions—always verify AI-generated code works as intended. Exploratory PRs or draft PRs for discussion are exceptions.
- When opening a PR, follow the PR template.
- When you'd like the team to take a look (even if the work is not yet fully complete) mark the PR as 'Ready For Review' so that the team can review your work and provide comments, suggestions, and request changes. It may take several cycles, but the end result will be solid, testable, conformant code that is safe for us to merge.
- When the PR is approved, let the owner of the PR merge it. For community contributions, the reviewer who approved the PR can also merge it.
- Use the
Squash and mergeoption to merge a PR. If you don't want to squash it because there are logically different commits, useRebase and merge. - Close issues automatically when referenced in a PR. You can use closing keywords in the body of the PR to have GitHub automatically link your PR to the issue.
Core Architecture
- Architecture Overview - Overview of the PowerToys architecture and module interface
- Runner and System tray - Details about the PowerToys Runner process
- Settings - Documentation on the settings system
- Installer - Information about the PowerToys installer
- Modules - Documentation for individual PowerToys modules
Common Components
- Context Menu Handlers - How PowerToys implements and registers Explorer context menu handlers
- Monaco Editor - How PowerToys uses the Monaco code editor component across modules
Tools
- Tools Overview - Overview of tools in PowerToys
- Build Tools - Tools that help building PowerToys
- Bug Report Tool - Tool for collecting logs and system information
- Debugging Tools - Specialized tools for debugging
- Fuzzing Testing - How to implement and run fuzz testing for PowerToys modules
Processes
- Release Process - How PowerToys releases are prepared and published
- Update Process - How PowerToys updates work
- GPO Implementation - Group Policy Objects implementation details
Other Resources
- aka.ms links - List of short links
- Issue/PR commands - Special commands for managing issues and pull requests
Building the Installer
Our installer is two parts, an EXE and an MSI. The EXE (Bootstrapper) contains the MSI and handles more complex installation logic.
- The EXE installs all prerequisites and installs PowerToys via the MSI. It has additional features such as the installation flags (see below).
- The MSI installs the PowerToys binaries.
The installer can only be compiled in Release mode; steps 1 and 2 must be performed before the MSI can be compiled.
- Compile
PowerToys.slnx. Instructions are listed above. - Compile
BugReportTool.slntool. Path from root:tools\BugReportTool\BugReportTool.sln(details listed below) - Compile
StylesReportTool.slntool. Path from root:tools\StylesReportTool\StylesReportTool.sln(details listed below) - Compile
PowerToysSetup.slnxPath from root:installer\PowerToysSetup.slnx(details listed below)
See Installer for more details on building and debugging the installer.