BraveBrowserStandaloneSetup.exe (64bit) doesn't install to C:Program Files, but rather C:Program Files (x86)
Installing from BraveBrowserStandaloneSetup.exe (64bit) on a 64bit Windows 10 places Brave into C:Program Files (x86) rather than C:Program Files
On 64bit Windows:
Brave installs to C:Program Files (x86) rather than C:Program Files
Install a 64bit version of Brave to C:Program Files
v1.11.104
Given Brave uses the Chrome installer, how does one produce installation logs or an MSI?
This is behavior of the installer unfortunately. We do have an issue open for being able to change the install directory, if you'd like to subscribe
https://github.com/brave/brave-browser/issues/598
Closing this issue as a duplicate
I don't believe this is an intentional behaviour of the installer, because the installer has support for
L"PROGRAMFILES", // With or without " (x86)" according to exe bitness.
L"PROGRAMFILES(X86)", // Always "C:\Program Files (x86)"
L"PROGRAMW6432", // Always "C:\Program Files" under WoW64.
https://github.com/chromium/chromium/blob/6efa1184771ace08f3e2162b0255c93526d1750d/base/base_paths_win.cc#L56
https://github.com/chromium/chromium/blob/55f44515cd0b9e7739b434d1c62f4b7e321cd530/chrome/install_static/product_install_details.cc#L62
I also note that #598 refers to a duplicate Chromium bug, which has been closed in favour of https://bugs.chromium.org/p/chromium/issues/detail?id=302491#c27 in which [email protected] has requested enterprise users make contact to confirm the demand for this feature.
Two reasons why I don't believe this should be closed as a duplicate.
ENVIRONMENT variable, which should require a tweaking of the existing code, rather than the addition of a new feature. I've checked the "exe bitness" of the installer files using a superuser guide and since they are 64bit, the installer should be correctly selecting the target path as C:\Program FilesC:\Program Files, that feature is completely different to the installer automatically selecting the correct target_path according to the system architecture@bsclifton Are we waiting for an upstream fix for this one?
@rebron can't hurt to wait for upstream; would be a nice to fix
Most helpful comment
I don't believe this is an intentional behaviour of the installer, because the installer has support for
https://github.com/chromium/chromium/blob/6efa1184771ace08f3e2162b0255c93526d1750d/base/base_paths_win.cc#L56
https://github.com/chromium/chromium/blob/55f44515cd0b9e7739b434d1c62f4b7e321cd530/chrome/install_static/product_install_details.cc#L62
I also note that #598 refers to a duplicate Chromium bug, which has been closed in favour of https://bugs.chromium.org/p/chromium/issues/detail?id=302491#c27 in which [email protected] has requested enterprise users make contact to confirm the demand for this feature.
Two reasons why I don't believe this should be closed as a duplicate.
ENVIRONMENTvariable, which should require a tweaking of the existing code, rather than the addition of a new feature. I've checked the "exe bitness" of the installer files using a superuser guide and since they are 64bit, the installer should be correctly selecting the target path asC:\Program FilesC:\Program Files, that feature is completely different to the installer automatically selecting the correct target_path according to the system architecture