<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
We need to release it manually.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [ ] **Closes:** #xxx
- [ ] **Communication:** I've discussed this with core contributors
already. If 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
---------
Co-authored-by: Yu Leng <yuleng@microsoft.com>
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
This PR introduces necessary changes to make the CmdPal.Apps extension
compatible with NativeAOT publishing. The main updates include:
1. Project configuration updates: Added NativeAOT-related properties to
the .csproj.
2. Native interop adjustments:
> - Introduced NativeMethods.json and used
[CsWin32](https://github.com/microsoft/cswin32) to generate P/Invoke
bindings.
> - Replaced some DllImport declarations with source-generated
[LibraryImport] for improved AOT support.
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
* Use source generation to replace some csWin32 function call.
* Clean up some AOT compatible issues.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [x] **Closes:** #39889
- [x] **Communication:** I've discussed this with core contributors
already. If 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
- [ ] **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
If you want to try it out, please see
https://github.com/microsoft/PowerToys/pull/39605
---------
Co-authored-by: Yu Leng <yuleng@microsoft.com>
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
Base on my test, some built-in extensions can be published with native
AOT enabled with a little changes. (see this branch:
https://github.com/microsoft/PowerToys/pull/39605).
1. SystemCommands: no change need. Removed some unused code.
2. WinGet: disable marshalling. and do a little changes in
CreateInstance.
3. WindowWalker: use source generation to call CoCreateInstance.
4. WindowsTerminal: use source generation to call
IApplicationActivationManager interface.
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
- [x] **Closes:** #39869
- [x] **Communication:** I've discussed this with core contributors
already. If 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
- [ ] **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
---------
Co-authored-by: Yu Leng <yuleng@microsoft.com>
<!-- Enter a brief description/summary of your PR here. What does it
fix/what does it change/how was it tested (even manually, if necessary)?
-->
## Summary of the Pull Request
Minor typo it's -> its
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
<!-- 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
README-only change
<!-- Describe how you validated the behavior. Add automated tests
wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
n/a
This was especially noticable with the icons extension.
Turns out in #39051, when I was experimenting with getting AoT clean,
i accidentally called this twice. Then we actually commited that
straight up.
This PR reverts that. It also moves a similar case where we were
initializing all the tags on the UI thread. That's wrong too - we need
to fetch properties off the UI thread, then update the list on the UI
thread.
Closes nothing, I didn't file this yet.
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
Since we change the launch method by this PR #39269 , we will start cmdpal as admin too if powertoys run as admin.
The fix is leveraging explorer (which will not run as admin) to start the cmdpal
Moreover, without this fix, some of extension cannot be "loaded" when cmdpal run as admin, e.g. winget will be missing, and my own new extension developed by myself will not be loaded successful as well.
Strong-name signing embeds publisher identity into the signature of a
.NET assembly.
This is required if *any other* strong name signed project wants to take
a dependency on it.
To make this work, we need to delay-sign it with a public key (.snk
file)--e.g. say we are going to sign it, but not actually sign it--to
give it an identity and then later submit it to ESRP for final signing.
The snk file does not contain any private material.
Some minor changes were required to build properly:
- `InternalsVisibleTo` requires a PublicKeyToken, but we aren't using
it in the SDK build so it's fine to just leave it out.
- I had to mark a class `sealed` and I can only guess it's because
strong named assemblies have more guarantees?
## Summary of the Pull Request
The Command Palette allows users to create extensions with dashes in their names, which is invalid for C# namespaces. This causes projects to fail during build because the name cannot be used as a valid namespace.
## Changes
- Updated the validation regex in `NewExtensionForm.cs` to only allow valid C# identifiers
- Now only allows names starting with a letter or underscore, followed by letters, numbers, or underscores
- Explicitly prevents dashes, spaces, and other special characters
- Improved the error message to clearly explain the requirements for valid C# identifiers
## Before
Previously, the input only validated that no spaces were used:
```csharp
"regex": "^[^\\s]+$"
```
## After
Now the input properly validates for C# namespace compatibility:
```csharp
"regex": "^[a-zA-Z_][a-zA-Z0-9_]*$"
```
This ensures that users cannot create extension projects with names that would fail to build.
## PR Checklist
- [ ] **Closes:** https://github.com/microsoft/PowerToys/issues/38522
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.
Updates .NET 9 Runtime / Library packages to the latest 9.0.5 servicing release for security fixes.
This PR also updates the version of System.Text.Json to 9.0.5 in the CmdPal extension template.
Data collection is hard.
Our internal package, which was last bumped around August 2024,
mistakenly changed a load bearing string from `ETW_GROUP` to
`MSPG_GROUP`. The former sets the ETW group id. The later does nothing.
This PR represents bumping our dependency to the version with the fix.
Considering that none of our data for CmdPal worked anyways, I took the
opportunity to rename a bunch of our events that had totally generic
names.
Closes#38704
re: #38032
regressed around: #34078
This bumps the version of the toolkit consumed by the template to 0.2.0
~Ironically, I have not yet published 0.2. I'm spinning that CI build currently. But I'll have that uploaded tomorrow morning at the latest~
EDIT: package is uploaded now
Extensions can change the properties on their Details, and they should
be observable, but they weren't. This is because the ShellPage is
ultimately responsible for exposing the details, but it doesn't own the
details. The selected ListItemViewModel from the ListPage does.
This PR just adds a event handler on ListViewModel. We'll attach/detach
that handler to ListItemViewModels as the selection changes. In the body
of that handler, we'll let the ShellPage know when the details object
changes (by sending ShowDetails/HideDetails messages).
Closes#39216
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
Card = AdaptiveCard.FromJsonString(cardJson) is called in catch block, if it fails, app will crash.
This PR stops us from synchronously initializing the settings page for every extension (including built-in's) on startup. That incurs a small penalty that really adds up the more extensions a user has.
Instead, we'll now only initialize the `CommandSettings` object when we first actually need it.
From a relatively unscientific test, this saves approximately 10% on the initialization of builtin commands, and for my setup, it trims about 28% off extension initialization (across all built-in's / extensions):
branch | Built-in load (ms) | Extension load (ms) | %Δ builtin | %Δ extensions |
-- | -- | -- | -- | -- |
main | 1455 | 6867.6 | | |
this PR | 1309.2 | 4919 | -10.02% | -28.37%
Closes#38321
* MinWidth/Height and DPI-aware launch dimensions
* Making MainWindow DPI aware too
* Moving toastwindow to WinUIEx too
* Update MainWindow.xaml.cs
* Reverting back to the working logic
* Localizing settings window title
* Xaml formatting
* Update SettingsWindow.xaml.cs
There's apparently a footgun with the way we're using ComServer, which
results in us leaking the extension processes when we think we've
disposed them
The fix unfortunately has to be on the extension side. Extensions
published prior to 0.2 will need to manually fix this.
closes: #39045
On a reload, the system commands fallback would leave the "restart"
fallback behind, for the same reason as what we found around
e40372c & ef264d9 in #38455
I cannot find an issue for this. I swear I filed it somewhere.
If you open winget, search for "terminal", wait till it loads, then
hit `esc`, we'll clear the search and empty the list, but never actually
hide the details pane. That looks weird.
This fixes that.
Closes _nothing i guess_.
This reduces our extension startup time by approximately 70% on my
machine (I have 17 extensions). I'd guess the gains scale with the
number of extensions. That's 8s -> 3s on average, and now I also get 2.5s reloads.
This retains the order of the list of extensions, by only starting the
processes in parallel. Once we have all the command provider instances,
then actually retrieving the commands.
It also adds a timeout on startup & load, so that one misbehaving extension won't block everyone else.
closes: #38529
Closes#38829
If we always UpdateProperty here, then there's a possible
race condition, where we raise the PropertyChanged(SearchText)
before the subclass actually retrieves the new SearchText from the
model. In that race situation, if the UI thread handles the
PropertyChanged before ListViewModel fetches the SearchText, it'll
think that the old search text is the _new_ value.
* Add Retry when enable
* Add correct for the checking logic
* Retry in another thread (#39042)
* launch thread
* dev
* fix a thread safety
* improve
* improve
* make code clear
* Fix comment
* fix comment
* improve
* self review
* fix & log
* silent fail if not reach 10 times
* fix a ci build flag error
* fix a macro
* some simple improve
---------
Co-authored-by: Gordon Lam (SH) <yeelam@microsoft.com>
* starting AoT flag push
* Few more
* bookmarks
* Really? The VM project compiles?
* Disable publish AOT before we really testing it.
---------
Co-authored-by: Mike Griese <migrie@microsoft.com>
Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com>
* add script to build a installer
* minor fix
* fix search path for msix file
* fix sign
* fix sign
* fix spelling
* Fix powershell5 can't recognize emoji
* ensure-wix
* bring cmdpal available during local build
* remove early quit
* fix marco
* add logger
* doc
* add a note
* self review
* fix macro def
* add functionality to export cert so that other machine can install it.
* spelling
_targets #38573_
At first I just wanted to add support for nested context menus.
But then I also had to add a search box, so the focus wouldn't get weird.
End result:
This gets rid of the need to have the search box and the command bar both track item keybindings - now it's just in the command bar.
Closes#38299Closes#38442
I'm filing this so that I don't lose it on this machine I use less often. We can probably hold it out of 0.90
Fixes:
* If a package is installed, we always display the version as "Unknown"
* also deals with a case where getting the package metadata could fail, and we'd hide the list item. That's only possible in the "installed, no updates available" case
* Allow package updates, add an icon for updates
* moves off the preview winget API onto a higher stable version
