[Automated] Add w4po.ExplorerTabUtility version 2.2.0

[w4po]

Checklist for Pull Requests

• Have you signed the Contributor License Agreement?
• Is there a linked Issue?

Manifests

• Have you checked that there aren't other open pull requests for the same manifest update/change?
• This PR only modifies one (1) manifest
• Have you validated your manifest locally with winget validate --manifest <path>?
• Have you tested your manifest locally with winget install --manifest <path>?
• Does your manifest conform to the 1.9 schema?

Note: <path> is the directory's name containing the manifest you're submitting.

---

Microsoft Reviewers: Open in CodeFlow

[wingetbot]

   

[wingetbot]

/AzurePipelines run

[w4po]

It works just fine, This is a standalone app (no installers);
Check for the system tray.

[w4po]

Hello @stephengillie,

As always, the automatic validation fails.
Please let me know if it is something that I can fix for the feature PRs.
Or is it because it is a standalone app?

You're awesome. Thanks for the support. ♥️

PR 221627 PR 228779

[DuckDuckStudio]

Hello @w4po
Here's where the problem may be coming from:

/~https://github.com/w4po/winget-pkgs/blob/70a49640d59bf5bae334031b076aeeed0ff27160/manifests/w/w4po/ExplorerTabUtility/2.2.0/w4po.ExplorerTabUtility.installer.yaml#L11

expltab: The term 'expltab' is not recognized as a name of a cmdlet, function, script file, or executable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

The suggested fix is to remove this line.
WinGet only adds the directory to the Path, the filename is still the same.

[w4po]

Hello @DuckDuckStudio,

I was testing using an elevated shell, so I didn't face the issue before.
Turns out it is an issue in the CLI,

I don't know if it is good enough to remove the alias,
As the original name is too long to type ExplorerTabUtility

Thank you for your support ♥️

[wingetbot]

/AzurePipelines run

[wingetbot]

/AzurePipelines run

[DuckDuckStudio]

I don't know if it is good enough to remove the alias, As the original name is too long to type ExplorerTabUtility

Personally I don't think this package should be opened by command, but that's still waiting for microsoft/winget-cli#2299 to implement it.

[wingetbot]

/AzurePipelines run

[w4po]

Personally I don't think this package should be opened by command, but that's still waiting for microsoft/winget-cli#2299 to implement it.

That would be much better ✨

Also, It seems PortableCommandAlias is not the issue, it must be something else.

[stephengillie]

Automatic Validation ended with:

Signature Update Failed. Failure to parse win 10, attempting win 11 Installation failed with exit code -1978335216 2025-03-01 15:48:17.905 [CORE] Deployment operation #0: error 0x800700EA: Failed to load the extension DLL due to the following error: More data is available. 2025-03-01 15:48:17.905 [FAIL] C:__w\1\s\external\pkg\src\AppInstallerCommonCore\Deployment.cpp(54)\WindowsPackageManager.dll!61D9DF27: (caller: 61D9E606) Exception(1) tid(1e00) 800700EA More data is available. Msg:[Operation failed: error 0x800700EA: Failed to load the extension DLL due to the following error: More data is available. Msg:[C:__w\1\s\external\pkg\src\AppInstallerCommonCore\Deployment.cpp(54)\WindowsPackageManager.dll!61D9DF27: (caller: 61D9E606) Exception(1) tid(1e00) 800700EA More data is available. 2025-03-01 15:48:17.925 [REPO] Source add/update failed, waiting 6292 milliseconds and retrying: winget

Automated error analysis suggests -1978335216 may mean None of the installers are applicable for the current system

(Automated response - build 986.)

[w4po]

I'm puzzled by the automatic validation failure as this appears to be a recurring issue with ExplorerTabUtility packages that doesn't reflect any actual problems:

1. The manifests are correctly structured and follow all Winget guidelines
2. The .NET 9 dependency is properly specified and available in the Winget repository
3. Previous versions of this package have been successfully merged after manual review despite similar automatic validation failures
4. End users can install the package without any issues using the winget command

The error message about "Failed to load the extension DLL" with code 0x800700EA suggests this might be a limitation in the validation environment rather than an issue with the package itself.

Could this be a known issue with the validation pipeline for certain types of packages?

I appreciate your help in getting this merged despite the automatic validation issues. If there's anything I can do to help troubleshoot or resolve these recurring validation failures for future updates, please let me know.