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?
* Update version to 0.91
Update version to 0.91
* Some PRs are still not included.
Some PRs are still not included.
* Add some PRs
* Add more PRs
* Add more PRs
* Add two more PRs
* Add some PRs
* Add one more PR
* Add all PRs up to this point, except for some documentation-related ones.
* Add the Highlights part
* Overall edits
* Add PRs about Doc changes
* Clean up the highlights section
* Update MD5
* Changed highlights and removed reg preview line item
* Put reg preview item back and updated highlights
---------
Co-authored-by: Kayla Cinnamon <cinnamon@microsoft.com>
## 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 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.
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_.
* 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>
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
