[Package Issue]: Google.Chrome.EXE, how to run it using CLI

[zengjiapei3000]

Please confirm these before moving forward

• I have searched for my issue and not found a work-in-progress/duplicate/resolved issue.
• I have not been informed if the issue is resolved in a preview version of the winget client.

Category of the issue

Installation issue.

Brief description of your issue

Want to run "Google.Chrome.EXE" using Powershell/CMD, but not work, maybe cause haven't add it to path environment variable.

Steps to reproduce

Want run it in Powershell/CMD, shell prompt not work.

Actual behavior

Shell prompt not work, and error message is:

chrome.exe : The term 'chrome.exe' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:1 char:1
+ chrome.exe
+ ~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (chrome.exe:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

Expected behavior

Shell prompt work.

Environment

PS C:\> winget --info
Windows Package Manager v1.9.25180
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.19044.5131
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.24.25180.0

Winget Directories
-----------------------------------------------------------------------------------------------------------------------
Logs                               %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\Diag…
User Settings                      %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\sett…
Portable Links Directory (User)    %LOCALAPPDATA%\Microsoft\WinGet\Links
Portable Links Directory (Machine) C:\Program Files\WinGet\Links
Portable Package Root (User)       %LOCALAPPDATA%\Microsoft\WinGet\Packages
Portable Package Root              C:\Program Files\WinGet\Packages
Portable Package Root (x86)        C:\Program Files (x86)\WinGet\Packages
Installer Downloads                D:\Downloads

Links
---------------------------------------------------------------------------
Privacy Statement   https://aka.ms/winget-privacy
License Agreement   https://aka.ms/winget-license
Third Party Notices https://aka.ms/winget-3rdPartyNotice
Homepage            https://aka.ms/winget
Windows Store Terms https://www.microsoft.com/en-us/storedocs/terms-of-sale

Admin Setting                             State
--------------------------------------------------
LocalManifestFiles                        Disabled
BypassCertificatePinningForMicrosoftStore Disabled
InstallerHashOverride                     Disabled
LocalArchiveMalwareScanOverride           Disabled
ProxyCommandLineOptions                   Enabled
DefaultProxy                              Disabled

Screenshots and Logs

[SpecterShell]

The EXE from the package identifier Google.Chrome.EXE doesn't mean it is a portable package. Instead it runs the EXE-based installer provided by Google, and whether Chrome would be added to PATH depends on that installer, which is not in this package.

[zengjiapei3000]

The EXE from the package identifier Google.Chrome.EXE doesn't mean it is a portable package. Instead it runs the EXE-based installer provided by Google, and whether Chrome would be added to PATH depends on that installer, which is not in this package.

Hello thanks for your reply : )

And I have another question for the package for Google.GoogleUpdater.
I just found a article to introduce difference between"Google.Chrome"and"Google.Chrome.EXE" from pckgr's blog site, it suggest user who using Google.Chrome.EXE also install Google.GoogleUpdater, I do that.

But when I run winget list to list packages, I haven't see the Google.GoogleUpdater package.
Does it a expected behavior?

[SpecterShell]

Yes, because the Google.GoogleUpdater installer does not write ARP entry to the registry (displayed in "Installed Apps" in the Settings app or "Apps and Features" in Control Panel), so WinGet could not find it after installation, but it is indeed installed. You should be able to find the related entries in Task Scheduler.