2022-03-18 17:47:18 +01:00
<Project>
2026-02-06 16:12:44 -08:00
<PropertyGroup>
<RepoRoot>$(MSBuildThisFileDirectory)</RepoRoot>
</PropertyGroup>
<Import Project="$(RepoRoot)src\Version.props" />
Advanced Paste additional customizations and PhiSilica provider (#46727)
## Summary
Adds an on-device **Phi Silica (Windows AI) paste provider** to Advanced
Paste and richer
per-action customization, plus the **package-identity plumbing** that
lets the unpackaged
Advanced Paste app use Windows AI APIs.
> Note: this supersedes the earlier "self-contained MSIX package
installed/registered by the
> WiX installer" approach. Advanced Paste is **not** packaged or
installed as a standalone
> MSIX. It keeps shipping as the existing unpackaged, self-contained
WinUI 3 executable in
> `WinUI3Apps/` and acquires **package identity at runtime from the
existing PowerToys sparse
> package** — there are no installer or ESRP MSIX repack changes.
## Advanced Paste features
- **New Phi Silica paste provider**
(`CustomActions/PhiSilicaPasteProvider.cs`): an on-device
AI provider backed by the Windows AI Phi Silica language model — no
cloud endpoint or API
key required. Registered as a new `AIServiceType` via
`PasteAIProviderFactory` /
`AIServiceTypeRegistry`.
- **Additional custom actions** (`AdvancedPasteAdditionalAction`):
user-defined actions with
their own prompt, system prompt, AI provider, and shortcut — plus an
optional "coaching"
prompt/system-prompt/provider/shortcut and shortcut-conflict detection.
- **Built-in default prompts** (`AdvancedPasteDefaultPrompts`) and
updates to
`AdvancedPasteCustomAction`, `PasteFormat(s)`, `OptionsViewModel`, and
`PasteFormatExecutor` to support per-action provider selection and
system prompts.
- **Settings UI** (`AdvancedPastePage.xaml`/`.xaml.cs`,
`Resources.resw`): configure the
Phi Silica provider, choose a provider per action, edit system/coaching
prompts, and a
Phi Silica availability/readiness experience — Settings queries the
Advanced Paste
executable via `--check-phi-silica`, and a **"Download model"** action
triggers
`--prepare-phi-silica` to fetch the model and then re-probes.
## Package identity for Windows AI (replaces the MSIX-install approach)
- Phi Silica is a **Limited Access Feature (LAF)** that can only be
unlocked by a process
with a registered **package identity**. Advanced Paste runs unpackaged,
so it obtains
identity from the existing **`Microsoft.PowerToys.SparseApp`** sparse
package
(`src/PackageIdentity/`): a new `<Application
Id="PowerToys.AdvancedPasteUI">` entry in
`AppxManifest.xml` maps it to `PowerToys.AdvancedPaste.exe`, with
matching updates to
`BuildSparsePackage.ps1`.
- **LAF unlock** at runtime via `PhiSilicaLafHelper.cs`. The
token/attestation are baked at
build time by the `GeneratePhiSilicaLafCredentials` MSBuild target into
`PhiSilicaLafCredentials.g.cs` — local **dev defaults** live in
`src/PhiSilicaLaf.props`
(imported from `Directory.Build.props`) and the **production secret** is
injected via
`/p:` in the release pipeline.
- New **`AdvancedPaste.dev.manifest` / `AdvancedPaste.prod.manifest`**
application manifests
(selected by `CIBuild`) declaring full-trust and the system AI models
capability.
## Build & pipeline
- **Windows App SDK** moved to the coherent **stable `2.2.0`** line and
**added
`Microsoft.WindowsAppSDK.AI` `2.2.3`** (the Phi Silica APIs). Foundation
`2.1.0` carries the
sparse-identity PRI fix, and the stable AI build matches the OS Windows
AI runtime.
- **Independent versioning** for Advanced Paste
(`src/modules/AdvancedPaste/custom.props`,
XES one-store versioning, `AdvancedPasteVersion`). A
`steps-setup-versioning.yml` step is
added for Advanced Paste in `job-build-project.yml`, ordered **before**
CmdPal to avoid a
version-collision installer failure (WIX0103).
- `release.yml` passes `PhiSilicaLafToken`/`PhiSilicaLafAttestation`
into the main build;
spell-check allow-list/patterns updated.
- Removed now-unneeded dependencies: the
`Microsoft.Windows.Compatibility` reference and the
`Common.UI` "force matching DLL versions" hack.
<img width="1073" height="716" alt="image"
src="https://github.com/user-attachments/assets/9364d86a-c0d1-4a08-a669-d98cbcb4b140"
/>
<img width="1038" height="308" alt="image"
src="https://github.com/user-attachments/assets/00eef1dd-b407-4841-bd64-f54f8a145c46"
/>
<img width="194" height="405" alt="image"
src="https://github.com/user-attachments/assets/d2f9c5bb-2507-4112-b3e0-56da681f88ea"
/>
<img width="489" height="453" alt="image"
src="https://github.com/user-attachments/assets/811d1afd-9993-48be-824e-82bb56c5ceca"
/>
[Video clip
internal](https://onedrive.cloud.microsoft/:v:/a@9n6nl3fp/S/cQpvAHrL5M9ZR6eUawztyfyBEgUCwCF-aKg9TbKyyGWP4c0KMA)
[Build
internal](https://microsoft.visualstudio.com/Dart/_build/results?buildId=149920754&view=artifacts&pathAsName=false&type=publishedArtifacts)
---------
Co-authored-by: Niels Laute <niels.laute@live.nl>
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
2026-08-07 22:43:59 -07:00
<Import Project="$(RepoRoot)src\PhiSilicaLaf.props" />
2022-03-18 17:47:18 +01:00
<PropertyGroup>
2024-01-18 18:47:54 +01:00
<Copyright>Copyright (C) Microsoft Corporation. All rights reserved.</Copyright>
<AssemblyCopyright>Copyright (C) Microsoft Corporation. All rights reserved.</AssemblyCopyright>
2022-03-18 17:47:18 +01:00
<AssemblyProduct>PowerToys</AssemblyProduct>
2024-08-05 06:32:05 -07:00
<AssemblyCompany>Microsoft Corp.</AssemblyCompany>
2022-03-18 17:47:18 +01:00
<Company>Microsoft Corporation</Company>
2024-08-05 06:32:05 -07:00
<Authors>Microsoft Corporation</Authors>
<Product>PowerToys</Product>
2022-03-18 17:47:18 +01:00
<NeutralLanguage>en-US</NeutralLanguage>
2022-04-07 05:48:05 -04:00
<Platforms>x64;ARM64</Platforms>
2022-03-21 13:48:52 +01:00
<PackageTags>PowerToys</PackageTags>
2022-03-18 17:47:18 +01:00
<EnableNETAnalyzers>true</EnableNETAnalyzers>
<AnalysisMode>Recommended</AnalysisMode>
2023-06-19 21:07:14 +02:00
<_SkipUpgradeNetAnalyzersNuGetWarning>true</_SkipUpgradeNetAnalyzersNuGetWarning>
2024-08-16 05:16:43 -04:00
<NuGetAuditMode>direct</NuGetAuditMode>
Add preview release versioning and update channel support (#49414)
## Summary
- Publish scheduled `main` builds as GitHub prereleases while keeping
manual `main` runs as preview validation builds.
- Add an opt-in Settings switch for prerelease update checks; stable
updates remain the default.
- Use one MSI-safe version across bundles, MSI packages, binaries,
symbols, and package manifests.
- Prevent preview releases from triggering Microsoft Store, WinGet, or
public-symbol publication.
- Label preview builds explicitly in Settings, update notifications, and
What's New.
## Build intent
| Source | Trigger | Intent |
| --- | --- | --- |
| `main` | Scheduled | Publish a preview release |
| `main` | Manual | Validate a preview build without publishing |
| `stable` | Manual | Produce a stable release |
| Other branches | Any supported trigger | Produce a private validation
build |
## MSI-safe release versioning
Windows Installer compares only `major.minor.build` and ignores the
fourth version component. Preview and stable release builds therefore
use:
```text
major.minor.YDDDB.0
```
- `Y`: zero-based number of calendar years since `ReleaseTrainEpoch`.
- `DDD`: three-position calendar day of year.
- `B`: daily release sequence `1-9`.
- The fourth component is always `0`.
With `ReleaseTrainVersion=0.100` and `ReleaseTrainEpoch=2026-01-01`:
```text
0.100.2111.0 = July 30, 2026, release build 1
0.100.3659.0 = December 31, 2026, release build 9
0.100.10011.0 = January 1, 2027, release build 1
```
The allocator formats `DDD` as exactly three digits before converting
the MSI component to its numeric representation. Leading zeros may not
be displayed because Windows version components are numeric; decoding
remains positional:
```text
B = component % 10
DDD = (component / 10) % 1000
Y = component / 10000
```
`ReleaseTrainVersion` and `ReleaseTrainEpoch` are checked in under
`src/Version.props`. The epoch remains January 1 of the active epoch
year and advances on the first release-train minor change in a new year.
## Daily release counter
Azure DevOps persists the daily sequence server-side using a counter
keyed as `release-YYYYMMDD`.
- `main` and `stable` share the same daily counter.
- Other branches do not evaluate or consume the release counter.
- Failed or canceled `main`/`stable` runs may leave gaps.
- The build fails when the daily sequence exceeds `9`.
- The counter date and encoded `YDDD` date both use
`pipeline.startTime`.
Private branches retain independent `0.0.<extended-day><NN>.0`
validation versions.
## Update behavior
- Stable users continue to query GitHub's stable latest-release path.
- Users who explicitly enable preview updates can select newer GitHub
prereleases.
- Preview releases and notifications are labeled as PowerToys Preview.
- What's New separates preview entries from stable release history and
hides previews by default.
## Validation
- 17 Pester tests cover `main`, `stable`, private branches, year
rollover, epoch reset, monotonicity, override validation, sequence
limits, and date alignment.
- Version propagation verified `0.100.2111.0` in `Version.props` and all
affected AppX/MSIX manifests.
- Azure DevOps pipeline dry-runs succeeded for both `refs/heads/main`
and `refs/heads/stable`.
- The affected native version project builds successfully.
- PR CI is green for x64, ARM64, Command Palette SDK, dependency review,
telemetry detection, and CLA.
## Remaining end-to-end checks
- Install two locally or officially produced installers with consecutive
MSI-visible `YDDDB` versions and verify the upgrade preserves binaries,
package registrations, hardlinks, and shell integrations.
- On the first natural post-merge `main` or `stable` run, verify the
production counter value and resolved version in the release logs.
## Local GPO verification
Validated locally with the signed `v0.100.2171` build from Azure DevOps
build
[153961073](https://microsoft.visualstudio.com/Dart/_build/results?buildId=153961073).
These checks cover the administrative-template integration and Settings
behavior.
### Policy enabled: preview updates are disabled
With `PreviewUpdatesDisabled=1`, **Include prerelease updates** is
forced off and locked, and Settings displays the
managed-by-your-organization notice.

### Policy removed: the user preference is preserved
After removing `PreviewUpdatesDisabled` and restarting PowerToys, the
previously selected preview-update preference is restored and editable.
The policy suppresses the preference without overwriting it.

### Group Policy Editor
After importing the updated ADMX/ADML templates, **Disable preview build
updates** appears under **Microsoft PowerToys > Installer and Updates**.
The policy dialog documents that **Enabled** blocks preview updates,
while **Disabled** or **Not Configured** leaves the choice available to
the user.

---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: ad8b7909-0472-4464-bdee-deaeca726f94
Copilot-Session: 8e04a72e-3b0f-4ac4-8156-d04ea9b8bb85
2026-08-06 23:45:11 +08:00
<IncludeSourceRevisionInInformationalVersion>false</IncludeSourceRevisionInInformationalVersion> <!-- Source commit is exposed explicitly via Version.props/version_gen.h. -->
2022-05-11 16:49:28 +01:00
<PlatformTarget>$(Platform)</PlatformTarget>
2026-03-04 15:46:42 -05:00
<RestoreEnablePackagePruning Condition=" '$(VisualStudioVersion)' == '17.0'">false </RestoreEnablePackagePruning>
2026-02-14 08:47:56 +01:00
<!-- Enable Microsoft.Testing.Platform -->
<EnableMSTestRunner>true</EnableMSTestRunner>
<TestingPlatformShowTestsFailure>true</TestingPlatformShowTestsFailure>
<TestingPlatformDotNetTestSupport>true</TestingPlatformDotNetTestSupport>
<TestingPlatformCommandLineArguments>$(TestingPlatformCommandLineArguments) --report-trx</TestingPlatformCommandLineArguments>
<!-- No arm64 agents to run the tests. -->
<TestingPlatformDisableCustomTestTarget Condition="'$(Platform)' == 'ARM64'">true</TestingPlatformDisableCustomTestTarget>
</PropertyGroup>
<!--
UI tests are run in dedicated UI test jobs/pipelines.
In CI, the main build uses `/t:Build;Test` across the full solution, so
prevent UI test projects from being executed in that pass.
-->
<PropertyGroup Condition="'$(TF_BUILD)' != '' and $(MSBuildProjectName.Contains('UITest'))">
<TestingPlatformDisableCustomTestTarget>true</TestingPlatformDisableCustomTestTarget>
2022-03-18 17:47:18 +01:00
</PropertyGroup>
Build: Fix release pipeline and local build failure (#45211)
## Summary of the Pull Request
Release pipeline is keeping failed, and local build failed at ut.
This pull request introduces changes to improve how test projects are
handled during release builds, ensuring that test code is not compiled
or analyzed when not needed - in doing release build, to - succeed the
execution and reduce built time.
And, to upgrade from VS17 to VS18 in cmdpal sdk build, this is to keep
consistency with all other build step
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [ ] Closes: #xxx
<!-- - [ ] Closes: #yyy (add separate lines for additional resolved
issues) -->
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Local build & release pipeline build should all pass:
Local build:
<img width="1815" height="281" alt="image"
src="https://github.com/user-attachments/assets/f350cf3f-b856-432d-97f3-e392d38ef7fa"
/>
Release pipeline is working too:
<img width="1195" height="163" alt="image"
src="https://github.com/user-attachments/assets/ce58de38-f0fb-45ad-9d70-2b8eb1c4db60"
/>
---------
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
2026-02-02 09:15:53 +08:00
<!--
Completely skip building test projects when BuildTests=false (e.g., Release pipeline).
This avoids InternalsVisibleTo/signing issues by not compiling test code at all.
Match: projects ending in Test, Tests, UnitTests, UITests, FuzzTests, or in a folder named Tests.
Also matches projects starting with UnitTests- (e.g., UnitTests-CommonLib).
Also removes all PackageReference/ProjectReference to prevent NuGet restore and dependency builds.
Note: Checking both 'false' and 'False' to handle YAML boolean serialization.
-->
<PropertyGroup Condition="'$(BuildTests)' == 'false' or '$(BuildTests)' == 'False'">
<_ProjectName>$(MSBuildProjectName)</_ProjectName>
<!-- Match any project ending with "Test" or "Tests" (covers UnitTests, UITests, FuzzTests, etc.) -->
<_IsSkippedTestProject Condition="$(_ProjectName.EndsWith('Test'))">true</_IsSkippedTestProject>
<_IsSkippedTestProject Condition="$(_ProjectName.EndsWith('Tests'))">true</_IsSkippedTestProject>
<!-- Match projects starting with UnitTests- or UITest- prefix -->
<_IsSkippedTestProject Condition="$(_ProjectName.StartsWith('UnitTests-'))">true</_IsSkippedTestProject>
<_IsSkippedTestProject Condition="$(_ProjectName.StartsWith('UITest-'))">true</_IsSkippedTestProject>
<!-- Match projects in a Tests folder -->
<_IsSkippedTestProject Condition="$(MSBuildProjectDirectory.Contains('\Tests\'))">true</_IsSkippedTestProject>
</PropertyGroup>
<PropertyGroup Condition="'$(_IsSkippedTestProject)' == 'true'">
<EnableDefaultItems>false</EnableDefaultItems>
<EnableDefaultCompileItems>false</EnableDefaultCompileItems>
<GenerateAssemblyInfo>false</GenerateAssemblyInfo>
<GenerateGlobalUsings>false</GenerateGlobalUsings>
<ImplicitUsings>disable</ImplicitUsings>
<!-- Disable all code analysis for skipped test projects -->
<EnableNETAnalyzers>false</EnableNETAnalyzers>
<RunAnalyzers>false</RunAnalyzers>
<RunAnalyzersDuringBuild>false</RunAnalyzersDuringBuild>
<TreatWarningsAsErrors>false</TreatWarningsAsErrors>
</PropertyGroup>
2022-03-21 13:48:52 +01:00
<PropertyGroup Condition="'$(MSBuildProjectExtension)' == '.csproj'">
Add preview release versioning and update channel support (#49414)
## Summary
- Publish scheduled `main` builds as GitHub prereleases while keeping
manual `main` runs as preview validation builds.
- Add an opt-in Settings switch for prerelease update checks; stable
updates remain the default.
- Use one MSI-safe version across bundles, MSI packages, binaries,
symbols, and package manifests.
- Prevent preview releases from triggering Microsoft Store, WinGet, or
public-symbol publication.
- Label preview builds explicitly in Settings, update notifications, and
What's New.
## Build intent
| Source | Trigger | Intent |
| --- | --- | --- |
| `main` | Scheduled | Publish a preview release |
| `main` | Manual | Validate a preview build without publishing |
| `stable` | Manual | Produce a stable release |
| Other branches | Any supported trigger | Produce a private validation
build |
## MSI-safe release versioning
Windows Installer compares only `major.minor.build` and ignores the
fourth version component. Preview and stable release builds therefore
use:
```text
major.minor.YDDDB.0
```
- `Y`: zero-based number of calendar years since `ReleaseTrainEpoch`.
- `DDD`: three-position calendar day of year.
- `B`: daily release sequence `1-9`.
- The fourth component is always `0`.
With `ReleaseTrainVersion=0.100` and `ReleaseTrainEpoch=2026-01-01`:
```text
0.100.2111.0 = July 30, 2026, release build 1
0.100.3659.0 = December 31, 2026, release build 9
0.100.10011.0 = January 1, 2027, release build 1
```
The allocator formats `DDD` as exactly three digits before converting
the MSI component to its numeric representation. Leading zeros may not
be displayed because Windows version components are numeric; decoding
remains positional:
```text
B = component % 10
DDD = (component / 10) % 1000
Y = component / 10000
```
`ReleaseTrainVersion` and `ReleaseTrainEpoch` are checked in under
`src/Version.props`. The epoch remains January 1 of the active epoch
year and advances on the first release-train minor change in a new year.
## Daily release counter
Azure DevOps persists the daily sequence server-side using a counter
keyed as `release-YYYYMMDD`.
- `main` and `stable` share the same daily counter.
- Other branches do not evaluate or consume the release counter.
- Failed or canceled `main`/`stable` runs may leave gaps.
- The build fails when the daily sequence exceeds `9`.
- The counter date and encoded `YDDD` date both use
`pipeline.startTime`.
Private branches retain independent `0.0.<extended-day><NN>.0`
validation versions.
## Update behavior
- Stable users continue to query GitHub's stable latest-release path.
- Users who explicitly enable preview updates can select newer GitHub
prereleases.
- Preview releases and notifications are labeled as PowerToys Preview.
- What's New separates preview entries from stable release history and
hides previews by default.
## Validation
- 17 Pester tests cover `main`, `stable`, private branches, year
rollover, epoch reset, monotonicity, override validation, sequence
limits, and date alignment.
- Version propagation verified `0.100.2111.0` in `Version.props` and all
affected AppX/MSIX manifests.
- Azure DevOps pipeline dry-runs succeeded for both `refs/heads/main`
and `refs/heads/stable`.
- The affected native version project builds successfully.
- PR CI is green for x64, ARM64, Command Palette SDK, dependency review,
telemetry detection, and CLA.
## Remaining end-to-end checks
- Install two locally or officially produced installers with consecutive
MSI-visible `YDDDB` versions and verify the upgrade preserves binaries,
package registrations, hardlinks, and shell integrations.
- On the first natural post-merge `main` or `stable` run, verify the
production counter value and resolved version in the release logs.
## Local GPO verification
Validated locally with the signed `v0.100.2171` build from Azure DevOps
build
[153961073](https://microsoft.visualstudio.com/Dart/_build/results?buildId=153961073).
These checks cover the administrative-template integration and Settings
behavior.
### Policy enabled: preview updates are disabled
With `PreviewUpdatesDisabled=1`, **Include prerelease updates** is
forced off and locked, and Settings displays the
managed-by-your-organization notice.

### Policy removed: the user preference is preserved
After removing `PreviewUpdatesDisabled` and restarting PowerToys, the
previously selected preview-update preference is restored and editable.
The policy suppresses the preference without overwriting it.

### Group Policy Editor
After importing the updated ADMX/ADML templates, **Disable preview build
updates** appears under **Microsoft PowerToys > Installer and Updates**.
The policy dialog documents that **Enabled** blocks preview updates,
while **Disabled** or **Not Configured** leaves the choice available to
the user.

---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: ad8b7909-0472-4464-bdee-deaeca726f94
Copilot-Session: 8e04a72e-3b0f-4ac4-8156-d04ea9b8bb85
2026-08-06 23:45:11 +08:00
<VersionBuildSuffix Condition="$([System.Text.RegularExpressions.Regex]::IsMatch('$(Version)', '^\d+\.\d+\.\d+$'))">.0</VersionBuildSuffix>
<VersionBuildSuffix Condition="'$(VersionBuildSuffix)' == ''"></VersionBuildSuffix>
<Version>$(Version)$(VersionBuildSuffix)</Version>
2024-08-14 18:07:43 +02:00
<RepositoryUrl>https://github.com/microsoft/PowerToys</RepositoryUrl>
2022-07-01 10:09:41 -04:00
<RepositoryType>GitHub</RepositoryType>
2022-03-18 17:47:18 +01:00
<TreatWarningsAsErrors>true</TreatWarningsAsErrors>
</PropertyGroup>
2020-12-14 15:20:45 +03:00
2020-04-29 13:02:18 -07:00
<PropertyGroup>
<_PropertySheetDisplayName>PowerToys.Root.Props</_PropertySheetDisplayName>
2026-02-06 16:12:44 -08:00
<ForceImportBeforeCppProps>$(RepoRoot)Cpp.Build.props</ForceImportBeforeCppProps>
2020-04-29 13:02:18 -07:00
</PropertyGroup>
Build: Fix release pipeline and local build failure (#45211)
## Summary of the Pull Request
Release pipeline is keeping failed, and local build failed at ut.
This pull request introduces changes to improve how test projects are
handled during release builds, ensuring that test code is not compiled
or analyzed when not needed - in doing release build, to - succeed the
execution and reduce built time.
And, to upgrade from VS17 to VS18 in cmdpal sdk build, this is to keep
consistency with all other build step
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [ ] Closes: #xxx
<!-- - [ ] Closes: #yyy (add separate lines for additional resolved
issues) -->
- [ ] **Communication:** I've discussed this with core contributors
already. If the work hasn't been agreed, this work might be rejected
- [ ] **Tests:** Added/updated and all pass
- [ ] **Localization:** All end-user-facing strings can be localized
- [ ] **Dev docs:** Added/updated
- [ ] **New binaries:** Added on the required places
- [ ] [JSON for
signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json)
for new binaries
- [ ] [WXS for
installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs)
for new binaries and localization folder
- [ ] [YML for CI
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml)
for new test projects
- [ ] [YML for signed
pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml)
- [ ] **Documentation updated:** If checked, please file a pull request
on [our docs
repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys)
and link it here: #xxx
<!-- Provide a more detailed description of the PR, other things fixed,
or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Local build & release pipeline build should all pass:
Local build:
<img width="1815" height="281" alt="image"
src="https://github.com/user-attachments/assets/f350cf3f-b856-432d-97f3-e392d38ef7fa"
/>
Release pipeline is working too:
<img width="1195" height="163" alt="image"
src="https://github.com/user-attachments/assets/ce58de38-f0fb-45ad-9d70-2b8eb1c4db60"
/>
---------
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
2026-02-02 09:15:53 +08:00
<ItemGroup Condition="'$(MSBuildProjectExtension)' == '.csproj' and '$(_IsSkippedTestProject)' != 'true'">
2023-02-13 12:10:33 -05:00
<PackageReference Include="StyleCop.Analyzers">
2022-07-19 22:40:40 +02:00
<PrivateAssets>all</PrivateAssets>
<IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
2024-08-14 18:07:43 +02:00
</PackageReference>
2026-02-06 16:12:44 -08:00
<Compile Include="$(RepoRoot)src\codeAnalysis\GlobalSuppressions.cs" Link="GlobalSuppressions.cs" />
<AdditionalFiles Include="$(RepoRoot)src\codeAnalysis\StyleCop.json" Link="StyleCop.json" />
2022-07-19 22:40:40 +02:00
2023-02-13 12:10:33 -05:00
<PackageReference Include="Microsoft.CodeAnalysis.NetAnalyzers">
2022-07-19 22:40:40 +02:00
<PrivateAssets>all</PrivateAssets>
<IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
</PackageReference>
</ItemGroup>
2026-02-14 08:47:56 +01:00
<!-- In CI, we build and test with `/t:Build;Test` -->
<!-- So, for non-test projects, we want the target to be there and it's basically doing nothing -->
<!-- For C# test projects, Microsoft.Testing.Platform should inject Test target here: -->
<!-- https://github.com/microsoft/testfx/blob/5ad21909704db501f58f27d4a7ec241edd761af5/src/Platform/Microsoft.Testing.Platform.MSBuild/buildMultiTargeting/Microsoft.Testing.Platform.MSBuild.targets#L270-L273 -->
<!-- For C++ test projects, the RunVSTest SDK will do its job -->
<Target Name="Test" />
<!-- Add ability to run tests via "msbuild /t:Test" using the RunVSTest SDK -->
<!-- This is only needed for C++, as we use Microsoft.Testing.Platform for C# -->
2024-04-16 19:08:23 -07:00
<!--
Updates for check-spelling v0.0.25 (#40386)
## Summary of the Pull Request
- #39572 updated check-spelling but ignored:
> 🐣 Breaking Changes
[Code Scanning action requires a Code Scanning
Ruleset](https://github.com/check-spelling/check-spelling/wiki/Breaking-Change:-Code-Scanning-action-requires-a-Code-Scanning-Ruleset)
If you use SARIF reporting, then instead of the workflow yielding an ❌
when it fails, it will rely on [github-advanced-security
🤖](https://github.com/apps/github-advanced-security) to report the
failure. You will need to adjust your checks for PRs.
This means that check-spelling hasn't been properly doing its job 😦.
I'm sorry, I should have pushed a thing to this repo earlier,...
Anyway, as with most refreshes, this comes with a number of fixes, some
are fixes for typos that snuck in before the 0.0.25 upgrade, some are
for things that snuck in after, some are based on new rules in
spell-check-this, and some are hand written patterns based on running
through this repository a few times.
About the 🐣 **breaking change**: someone needs to create a ruleset for
this repository (see [Code Scanning action requires a Code Scanning
Ruleset: Sample ruleset
](https://github.com/check-spelling/check-spelling/wiki/Breaking-Change:-Code-Scanning-action-requires-a-Code-Scanning-Ruleset#sample-ruleset)).
The alternative to adding a ruleset is to change the condition to not
use sarif for this repository. In general, I think the github
integration from sarif is prettier/more helpful, so I think that it's
the better choice.
You can see an example of it working in:
- https://github.com/check-spelling-sandbox/PowerToys/pull/23
---------
Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>
Co-authored-by: Mike Griese <migrie@microsoft.com>
Co-authored-by: Dustin L. Howett <dustin@howett.net>
2025-07-08 18:16:52 -04:00
Work around an MSBuild bug where Microsoft.Common.Test.targets is missing from the Arm64 installation.
2024-04-16 19:08:23 -07:00
See: https://github.com/dotnet/msbuild/pull/9984
NB 1: This means that using "/t:Test" is not supported for Arm64 builds and tests will need to be run in an alternate way,
eg running tests in VS or invoking vstest.console directly.
NB 2: <Sdk> elements do not support conditions, so this is also being worked around.
Once the change referenced above is fixed, the ImportGroup below can be replaced with:
<Sdk Name="Microsoft.Build.RunVSTest" Version="1.0.319" />
-->
2026-02-14 08:47:56 +01:00
<ImportGroup Condition="'$(PROCESSOR_ARCHITECTURE)' != 'ARM64' AND ('$(Language)' == 'C++' OR '$(MSBuildProjectExtension)' == '.vcxproj')">
2024-04-16 19:08:23 -07:00
<Import Project="Sdk.props" Sdk="Microsoft.Build.RunVSTest" Version="1.0.319" />
<Import Project="Sdk.targets" Sdk="Microsoft.Build.RunVSTest" Version="1.0.319" />
</ImportGroup>
2026-02-14 08:47:56 +01:00
<PropertyGroup Condition="'$(Language)' == 'C++' OR '$(MSBuildProjectExtension)' == '.vcxproj'">
2024-04-02 11:47:58 -07:00
<VSTestLogger>trx</VSTestLogger>
<!--
RunVSTest by default uses %VSINSTALLDIR%\Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe,
but some of the CI scenarios don't define %VSINSTALLDIR%, so be explicit about where to look for vstest.
Note: $(VsInstallRoot) is a built-in MSBuild property, so should always be defined.
-->
<VSTestToolPath>$(VsInstallRoot)\Common7\IDE\CommonExtensions\Microsoft\TestWindow</VSTestToolPath>
<!-- No arm64 agents to run the tests. -->
<RunVSTest Condition="'$(Platform)' == 'ARM64'">false</RunVSTest>
</PropertyGroup>
2024-01-15 13:45:28 -08:00
<!-- MSBuildCache -->
<PropertyGroup>
<!-- Off by default -->
<MSBuildCacheEnabled Condition="'$(MSBuildCacheEnabled)' == ''">false</MSBuildCacheEnabled>
<!-- In Azure pipelines, use Pipeline Caching as the cache storage backend. Otherwise, use the local cache. -->
<MSBuildCachePackageName Condition="'$(TF_BUILD)' != ''">Microsoft.MSBuildCache.AzurePipelines</MSBuildCachePackageName>
<MSBuildCachePackageName Condition="'$(MSBuildCachePackageName)' == ''">Microsoft.MSBuildCache.Local</MSBuildCachePackageName>
</PropertyGroup>
<PropertyGroup Condition="'$(MSBuildCacheEnabled)' == 'true'">
2024-03-22 03:29:14 -07:00
<!-- Disable when running in a pipeline as the time to upload or download the massive .pch/.pchast to the cache is greater than the savings they provide. -->
<UsePrecompiledHeaders Condition="'$(TF_BUILD)' != ''">false</UsePrecompiledHeaders>
2024-01-15 13:45:28 -08:00
<!-- Change this to bust the cache -->
2024-08-15 17:29:25 +02:00
<MSBuildCacheCacheUniverse Condition="'$(MSBuildCacheCacheUniverse)' == ''">202408150737</MSBuildCacheCacheUniverse>
2024-01-15 13:45:28 -08:00
<!--
2024-01-30 13:36:25 -08:00
Visual Studio telemetry reads various ApplicationInsights.config files and other files after the project is finished, likely in a detached process.
This is acceptable and should not impact cache correctness.
2024-01-15 13:45:28 -08:00
-->
2024-01-30 13:36:25 -08:00
<MSBuildCacheAllowFileAccessAfterProjectFinishFilePatterns>
$(MSBuildCacheAllowFileAccessAfterProjectFinishFilePatterns);
\**\ApplicationInsights.config;
$(LocalAppData)\Microsoft\VSApplicationInsights\**;
$(LocalAppData)\Microsoft\Windows\INetCache\**;
A:\;
E:\;
2024-04-09 11:53:24 -07:00
$(windir)\**;
2024-01-30 13:36:25 -08:00
</MSBuildCacheAllowFileAccessAfterProjectFinishFilePatterns>
2024-01-15 13:45:28 -08:00
2024-04-02 11:47:58 -07:00
<!-- Unit tests of low-priv processes, eg the preview handler tests, may log to this location. -->
<MSBuildCacheAllowFileAccessAfterProjectFinishFilePatterns>
$(MSBuildCacheAllowFileAccessAfterProjectFinishFilePatterns);
$(USERPROFILE)\AppData\LocalLow\Microsoft\PowerToys\**;
</MSBuildCacheAllowFileAccessAfterProjectFinishFilePatterns>
2026-04-30 02:40:43 -04:00
<!-- dotnet.exe seems to access files after builds. Temporarily putting in this entry for testing if we get further. This looks to be related to a .NET Roslyn Analyzer in .NET 10-->
<MSBuildCacheAllowFileAccessAfterProjectFinishProcessPatterns>
$(MSBuildCacheAllowFileAccessAfterProjectFinishProcessPatterns);
\**\dotnet\dotnet.exe;
\**\vbcscompiler.exe;
</MSBuildCacheAllowFileAccessAfterProjectFinishProcessPatterns>
2024-01-15 13:45:28 -08:00
<!--
This repo uses a common output directory with many projects writing duplicate outputs. Allow everything, but note this costs some performance in the form of requiring
the cache to use copies instead of hardlinks when pulling from cache.
-->
<MSBuildCacheIdenticalDuplicateOutputPatterns>$(MSBuildCacheIdenticalDuplicateOutputPatterns);**</MSBuildCacheIdenticalDuplicateOutputPatterns>
<!-- version of MSBuildCache is not part of the cache key -->
<PackagesConfigFile>$(MSBuildThisFileDirectory)packages.config</PackagesConfigFile>
<MSBuildCacheIgnoredInputPatterns>$(MSBuildCacheIgnoredInputPatterns);$(PackagesConfigFile)</MSBuildCacheIgnoredInputPatterns>
</PropertyGroup>
<PropertyGroup Condition="'$(MSBuildCacheEnabled)' == 'true' and '$(MSBuildCachePackageRoot)' == ''">
<PackagesConfigContents>$([System.IO.File]::ReadAllText("$(PackagesConfigFile)"))</PackagesConfigContents>
<MSBuildCachePackageVersion>$([System.Text.RegularExpressions.Regex]::Match($(PackagesConfigContents), 'Microsoft.MSBuildCache.*?version="(.*?)"').Groups[1].Value)</MSBuildCachePackageVersion>
<MSBuildCachePackageRoot>$(MSBuildThisFileDirectory)packages\$(MSBuildCachePackageName).$(MSBuildCachePackageVersion)</MSBuildCachePackageRoot>
<MSBuildCacheSharedCompilationPackageRoot>$(MSBuildThisFileDirectory)packages\Microsoft.MSBuildCache.SharedCompilation.$(MSBuildCachePackageVersion)</MSBuildCacheSharedCompilationPackageRoot>
</PropertyGroup>
<ImportGroup Condition="'$(MSBuildCacheEnabled)' == 'true'">
<Import Project="$(MSBuildCachePackageRoot)\build\$(MSBuildCachePackageName).props" />
<Import Project="$(MSBuildCacheSharedCompilationPackageRoot)\build\Microsoft.MSBuildCache.SharedCompilation.props" />
</ImportGroup>
2024-01-18 18:47:54 +01:00
</Project>