This will ensure that the command palette package is copied to the artifact directory.
If code signing was enabled, the final copied package will be the signed version.
Minor build rule rearranging was required to collect the command palette package
path for the staging step when signing was _disabled_. I did this solely so that we
could verify the results in CI.
This pull request adopts the unified versioning scheme used by Windows Terminal, Notepad, and hundreds of other internal and public projects that relied on "XES" or "PackageES".
It only does so for the command palette.
All command palette assets will be versioned according to the Major and Minor number in `src/modules/cmdpal/custom.props`. This includes DLLs, EXEs, NuGet packages and MSIX bundles.
This will ensure that all artifacts that we produce are versioned
properly:
| thing | version (ex.) |
|---------|-----------------|
| dll/exe | 0.2.2505.08001 |
| nupkg | 0.2.250508001 |
| appx | 0.2.3269.0 |
For reference, here's the version format:
### EXE, DLL, .NET Assembly
0.2.2505.08001
^ ^ ^ ^ ^ ^
| | | | | `-Build # on that date
| | | | `-Day
| | | `-Month
| | `-Year
| `-Minor
`-Major
### NuGet Package
0.2.250508001
^ ^ ^ ^ ^ ^
| | | | | `-Build # on that date
| | | | `-Day
| | | `-Month
| | `-Year
| `-Minor
`-Major
### AppX Package
0.2.01281.0 (the leading 0 will be removed)
^ ^ ^ ^^ ^
| | | || `-Contractually always zero (a waste)
| | | |`-Build # on that date
| | | `-Number of days in [base year]
| | `-Number of years since [base year]
| `-Minor
`-Major
[base year] = $(XesBaseYearForStoreVersion)
It is expected that the base year is changed every time the version
number is changed.
* Add Powershell script to validate whether CSharp project correctly import shared props, update pipeline to enforce such validation, and fixed all projects that didn't import this shared props correctly
* add common props for fuzz test project
* update the path
* Only scans projects in src sub-folder
* Update .pipelines/verifyCommonProps.ps1
* Update csproj to include Common.Dotnet.CsWinRT.props
* Fix indentation in RegistryPreview.FuzzTests.csproj
* exclude TemplateCmdPalExtension.csproj in validation process
* exclude TemplateCmdPalExtension.csproj in validation process
---------
Co-authored-by: Leilei Zhang <leilzh@microsoft.com>
Co-authored-by: Jerry Xu <nxu@microsoft.com>
Windows Command Palette ("CmdPal") is the next iteration of PowerToys Run. With extensibility at its core, the Command Palette is your one-stop launcher to start _anything_.
By default, CmdPal is bound to <kbd>Win+Alt+Space</kbd>.
----
This brings the current preview version of CmdPal into the upstream PowerToys repo. There are still lots of bugs to work out, but it's reached the state we're ready to start sharing it with the world. From here, we can further collaborate with the community on the features that are important, and ensuring that we've got a most robust API to enable developers to build whatever extensions they want.
Most of the built-in PT Run modules have already been ported to CmdPal's extension API. Those include:
* Installed apps
* Shell commands
* File search (powered by the indexer)
* Windows Registry search
* Web search
* Windows Terminal Profiles
* Windows Services
* Windows settings
There are a couple new extensions built-in
* You can now search for packages on `winget` and install them right from the palette. This also powers searching for extensions for the palette
* The calculator has an entirely new implementation. This is currently less feature complete than the original PT Run one - we're looking forward to updating it to be more complete for future ingestion in Windows
* "Bookmarks" allow you to save shortcuts to files, folders, and webpages as top-level commands in the palette.
We've got a bunch of other samples too, in this repo and elsewhere
### PowerToys specific notes
CmdPal will eventually graduate out of PowerToys to live as its own application, which is why it's implemented just a little differently than most other modules. Enabling CmdPal will install its `msix` package.
The CI was minorly changed to support CmdPal version numbers independent of PowerToys itself. It doesn't make sense for us to start CmdPal at v0.90, and in the future, we want to be able to rev CmdPal independently of PT itself.
Closes#3200, closes#3600, closes#7770, closes#34273, closes#36471, closes#20976, closes#14495
-----
TODOs et al
**Blocking:**
- [ ] Images and descriptions in Settings and OOBE need to be properly defined, as mentioned before
- [ ] Niels is on it
- [x] Doesn't start properly from PowerToys unless the fix PR is merged.
- https://github.com/zadjii-msft/PowerToys/pull/556 merged
- [x] I seem to lose focus a lot when I press on some limits, like between the search bar and the results.
- This is https://github.com/zadjii-msft/PowerToys/issues/427
- [x] Turned off an extension like Calculator and it was still working.
- Need to get rid of that toggle, it doesn't do anything currently
- [x] `ListViewModel.<FetchItems>` crash
- Pretty confident that was fixed in https://github.com/zadjii-msft/PowerToys/pull/553
**Not blocking / improvements:**
- Show the shortcut through settings, as mentioned before, or create a button that would open CmdPalette settings.
- When PowerToys starts, CmdPalette is always shown if enabled. That's weird when just starting PowerToys/ logging in to the computer with PowerToys auto-start activated. I think this should at least be a setting.
- Needing to double press a result for it to do the default action seems quirky. If one is already selected, I think just pressing should be enough for it to do the action.
- This is currently a setting, though we're thinking of changing the setting even more: https://github.com/zadjii-msft/PowerToys/issues/392
- There's no URI extension. Was surprised when typing a URL that it only proposed a web search.
- [x] There's no System commands extension. Was expecting to be able to quickly restart the computer by typing restart but it wasn't there.
- This is in PR https://github.com/zadjii-msft/PowerToys/pull/452
---------
Co-authored-by: joadoumie <98557455+joadoumie@users.noreply.github.com>
Co-authored-by: Jordi Adoumie <jordiadoumie@microsoft.com>
Co-authored-by: Mike Griese <zadjii@gmail.com>
Co-authored-by: Niels Laute <niels.laute@live.nl>
Co-authored-by: Michael Hawker <24302614+michael-hawker@users.noreply.github.com>
Co-authored-by: Stefan Markovic <57057282+stefansjfw@users.noreply.github.com>
Co-authored-by: Seraphima <zykovas91@gmail.com>
Co-authored-by: Jaime Bernardo <jaime@janeasystems.com>
Co-authored-by: Kristen Schau <47155823+krschau@users.noreply.github.com>
Co-authored-by: Eric Johnson <ericjohnson327@gmail.com>
Co-authored-by: Ethan Fang <ethanfang@microsoft.com>
Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com>
Co-authored-by: Clint Rutkas <clint@rutkas.com>
* for testing az
* change file
* update test
* install python
* update
* test
* use powershell
* tes
* update enve
* update
* test
* add
* test
* merge
* az
* change
* update
* test cli
* add debug
* test large
* fix
* use templete
* fix x64 python install
* for testing
* add
* fix
* use 3.11.1
* change for test
* revert some testing file
* update the file name for spelling check
* use azure cli zip
* use aka.ms
* rename the zip file
* Remove all VideoConferenceMute related code and files
* Clean up vcm driver registry keys
* Also remove the Webcam report tool
* Also clean out video conference on the installer
* Fix spellcheck
* Remove comment about video conf
* Update gpo files revision
* Revert removing the VCM policies
* Deprecate VCM GPO policy
* Change deprecation message to show first supported version
* Tweak supported strings in the adml
This PR introduces the following changes to the CI pipeline and version management:
Pipeline Enhancements:
1. Added a new script UpdateVersions.ps1 to automate the update of Microsoft.WindowsAppSDK versions across various project files.
2. Introduced a new pipeline configuration ci-using-the-latest-winappsdk.yml to build using the latest Microsoft.WindowsAppSDK.
3. Updated existing pipeline configurations to support the new useLatestWinAppSDK parameter.
Pipeline Configuration Updates:
1. Updated job-build-project.yml to handle the useLatestWinAppSDK parameter and adjust the RestoreAdditionalProjectSourcesArg accordingly.
2. Added a new template steps-update-winappsdk-and-restore-nuget.yml for updating and restoring NuGet packages with the latest Microsoft.WindowsAppSDK.
3. Added WinAPPSDK version selection, the pipeline can be manually triggered to use the specified version.
---------
Signed-off-by: Shawn Yuan <shuai.yuan.zju@gmail.com>
Co-authored-by: Clint Rutkas <clint@rutkas.com>
* [Deps] Upgrade Framework Libraries to .NET 9 RC2
* [Common][Build] Update TFM to NET9
* [FileLocksmith][Build] Update TFM to NET9 in Publish Profile
* [PreviewPane][Build] Update TFM to NET9 in Publish Profile
* [PTRun][Build] Update TFM to NET9 in Publish Profile
* [Settings][Build] Update TFM to NET9 in Publish Profile
* [MouseWithoutBorders][Analyzers] Resolve WFO1000 by configuring Designer Serialization Visibility
* [Deps] Update Microsoft.CodeAnalysis.NetAnalyzers
* [Analyzers] Set CA1859,CA2263,CA2022 to be excluded from error
* [MouseWithoutBorders] Use System.Threading.Lock to lock instead of object instance
* [ColorPicker] Use System.Threading.Lock to lock instead of object instance
* [AdvancedPaste] Use System.Threading.Lock to lock instead of object instance
* [TextExtractor] Use System.Threading.Lock to lock instead of object instance
* [Hosts] Use System.Threading.Lock to lock instead of object instance
* [MouseJump] Use System.Threading.Lock to lock instead of object instance
* [PTRun] Use System.Threading.Lock to lock instead of object instance
* [Wox] Use System.Threading.Lock to lock instead of object instance
* [Peek] Use System.Threading.Lock to lock instead of object instance
* [PowerAccent] Use System.Threading.Lock to lock instead of object instance
* [Settings] Use System.Threading.Lock to lock instead of object instance
* [Deps] Update NOTICE.md
* [CI] Update .NET version step to target 9.0
* [Build] Attempt to add manual trigger for using Visual Studio Preview for building
* [Build] Fix variable typo
* [Build][Temporary] set to use preview builds
* [Build] Add missing parameters
* [Build][Temporary] directly hardcode preview image
* [Build][Temporary] Trying ImageOverride
* [Build] Revert hardcode and use ImageOverride
* [Build] Add env var for adding prerelease argument for vswhere
* [Build] Update VCToolsVersion script to use env var to optionally add prerelease version checking
* [Build] Remove unneeded parameter
* [Build] Re-add parameter in all the right places
* [CI][Build] Add NoWarn NU5104 when building with VS Preview
* [Deps] Update to stable .NET 9 packages
* [Deps] Update NOTICE.md
* Everything is WPF and WindowsForms now to fix .NET 9 dependency conflicts
* Ensure .NET 9 SDK for tests too
---------
Co-authored-by: Jaime Bernardo <jaime@janeasystems.com>
After we upgraded Windows App SDK to 1.6, Dev Files Preview on Peek has been broken on ARM64.
For .86, we've added WebView2 to Registry Preview in order to have Monaco Editor as the text editor, which is also broken on ARM64.
After a lengthy investigation, it seems we've found the core issue, PowerToys has been shipping with a x64 Microsoft.Web.WebView2.Core.dll in the ARM64 installer, which fails at runtime.
We seem to have hit a version of https://github.com/microsoft/WindowsAppSDK/issues/4826
When we build PowerToys in Dart for release, we publish some of the C# WinUI3Apps after building PowerToys and before signing / building the install. This means that the WindowsAppSDK build will recopy its WebView2 dependency, which for some reason is ARM64. On local builds of PowerToys, PowerRename, a C++ WinAppSDK application finished last, which copies the right dll and it's the reason we weren't being able to repro the issue on local builds of ARM64 PowerToys.
This PR solves the issue by including a short time hack in the CI to copy the right dll after publishing the C# WinUI3Apps when building for ARM64.
## Validation Steps Performed
Waiting for 4 concurrent builds of ARM64 from Dart to test whether the problem is solved.
XAML style checkers aren't running right now in PR CI. This allowed some XAML style errors to cause build errors in release CI.
This PR contains the following fixes:
- Fix XAML style of files that have slipped.
- Add errors to the scripts that depend on dotnet commands if it fails.
- Add .NET 6 on CI so that applyXamlStyling.ps1 and verifyNugetPackages.ps1 run correctly again.
-t:Pack is insufficient for packing a NuGet package after you've signed the DLLs.
Without -p:NoBuild=true, sometimes it will rebuild (or re-link) them for you.
This pull request rewrites the entire Azure DevOps build system.
The guiding principles behind this rewrite are:
- No pipeline definitions should contain steps (or tasks) directly.
- All jobs should be in template files.
- Any set of steps that is reused across multiple jobs must be in
template files.
- All artifact names can be customized (via a property called
`artifactStem` on all templates that produce or consume artifacts).
- No compilation happens outside of the "Build" phase, to consolidate
the production and indexing of PDBs.
- All step and job templates are named with `step` or `job` _first_,
which disambiguates them in the templates directory.
- Most jobs can be run on different `pool`s, so that we can put
expensive jobs on expensive build agents and cheap jobs on cheap
build agents. Some jobs handle pool selection on their own, however.
Our original build pipelines used the `VSBuild` task _all over the
place._ This resulted in PowerToys being built in myriad ways, different
for every pipeline. There was an attempt at standardization early on,
where `ci.yml` consumed jobs and steps templates... but when
`release.yml` was added, all of that went out the window.
It's the same story as Terminal (https://github.com/microsoft/terminal/pull/15808).
The new pipelines are consistent and focus on a small, well-defined set
of jobs:
- `job-build-project`
- This is the big one!
- Takes a list of build configurations and platforms.
- Produces an artifact named `build-PLATFORM-CONFIG` for the entire
matrix of possibilities.
- Builds all of the installers.
- Optionally signs the output (all of the output).
- Admittedly has a lot going on.
- `job-test-project`
- Takes **one** build config and **one** platform.
- Consumes `build-PLATFORM-CONFIG`
- Selects its own pools (hardcoded) because it knows about
architectures and must choose the right agent arch.
- Runs tests (directly on the build agent).
- `job-publish-symbols-using-symbolrequestprod-api`
- Consumes `**/*.pdb` from all prior build phases.
- Uploads all PDBs in one artifact to Azure DevOps
- Uses Microsoft's internal symbol publication REST API to submit
stripped symbols to MSDL for public consumption.
Finally, this pull request has some additional benefits:
- Symbols are published to the private and public feeds at the same
time, in the same step. They should be available in the public symbol
server for public folks to debug against!
- We have all the underpinnings necessary to run tests on ARM64 build
agents.
- Right now, `ScreenResolutionUtility` is broken
- I had to introduce a custom version of `UseDotNet` which would
install the right architecture (🤦); see https://github.com/microsoft/azure-pipelines-tasks/issues/20300.
- All dotnet and nuget versioning is consolidated into a small set of
step templates.
- This will provide a great place for us to handle versioning changes
later, since all versioning happens in one place.
