The `flutter doctor` command uses `vswhere.exe` to verify the Visual Studio installation. This `vswhere.exe` is known to encode its output incorrectly. This is problematic as the `description` property is localized, and in certain languages this results in invalid JSON due to the incorrect encoding.
This change introduces a fallback to our `vswhere.exe` output parsing logic: if parsing JSON fails, remove the `description` property and retry parsing the JSON.
This fix was also tested on the outputs provided here: https://github.com/flutter/flutter/issues/106601#issuecomment-1170138123
Addresses https://github.com/flutter/flutter/issues/106601
Flutter uses `vswhere.exe` to find Visual Studio installations and determine if they satisfy Flutter's requirements. However, `vswhere.exe`'s JSON output is known to contain bad UTF-8. This change ignores bad UTF-8 as long as they affect JSON properties that are either unused, or, used only for display purposes by Flutter.
Fixes: https://github.com/flutter/flutter/issues/102451
`VisualStudio` calls `vswhere.exe` to find Visual Studio installations and determine if they satisfy Flutter's requirements. Previously, `VisualStudio` stored the JSON output from `vswhere.exe` as `Map`s, resulting in duplicated logic to read the JSON output (once to validate values, second to expose values). Also, `VisualStudio` stored two copies of the JSON output (the latest valid installation as well as the latest VS installation).
This change simplifies `VisualStudio` by introducing a new `VswhereDetails`. This type contains the logic to read `vswhere.exe`'s JSON output, and, understand whether an installation is usable by Flutter. In the future, this `VswhereDetails` type will be used to make Flutter doctor resilient to bad UTF-8 output from `vswhere.exe`.
Part of https://github.com/flutter/flutter/issues/102451.
Windows plugins are designed to share implementations between Win32 and
UWP, but not all plugins will support both. This adds a new
'supportedVariants' key to Windows plugins that allows specifying
'win32' and/or 'uwp' (and potentially others in the future in case that
becomes necessary).
Plugins without any supported variants will be assumed to be Win32 for
backward compatibility.
This will allow compiling Windows projects that use Win32-only Windows
plugins (which is currently all of them) in UWP mode. The plugins will
of course throw missing implementation exceptions at runtime, but tehy
won't prevent being able to build as they currently do.
Fixes https://github.com/flutter/flutter/issues/82815
Depending on the user's build configuration, we may output
multi-architecture or single-architecture binaries. Prefer to install
the multi-architecture binary if built, otherwise fall back to the
single-architecture binary.
This eliminates the use of the Install.ps1 script during Windows app
installation and instead uses uwptool install. Install.ps1 was the
slowest part of app install, and had resource contention issues that
frequently caused it to fail.
Adds UwpTool.install and UwpTool.uninstall methods. Refactors the
PowerShell-based install code to move the powershell-related bits out of
the Device class and into UwpTool so that when we swap out the
PowerShell-based install for the uwptool-based install, it's transparent
to the WindowsUWPDevice class.
Adds implementations for:
* WindowsUWPDevice.isAppInstalled
* WindowsUWPDevice.uninstallApp
Refactors:
* WindowsUWPDevice.installApp
Allow flutter run to work end-to-end with a UWP device.
Uses win32/ffi for the actual launch of the application, injected via
the native API class. This is structured to avoid a g3 dependency.
Install and amuid require powershell scripts for now.
Actually connecting to the observatory requires running a command in an
elevated prompt. Instructions are presented to the user if a terminal is
attached.
This is a rebased version of https://github.com/flutter/flutter/pull/79684
by @jonahwilliams, updated to remove `NativeApi` and replace is with calls
to `uwptool`.
Part of https://github.com/flutter/flutter/issues/82085
Refactors the desktop devices and workflow to remove unnecessary usage of global variables. This should make it easier to test and continue enhancing the desktop functionality of the tooling
#47161
* First pass at CMake files; untested
* First pass of adding CMake generation logic on Windows
* Misc fixes
* Get bundling working, start incoprorating CMake build into tool
* Fix debug, exe name.
* Add resources
* Move cmake.dart
* Rip out all the vcxproj/solution plumbing
* Fix plugin cmake generation
* Build with cmake rather than calling VS directly
* Adjust Windows plugin template to match standard header directory structure
* Pass config selection when building
* Partially fix multi-config handling
* Rev template version
* Share the CMake generation instead of splitting it out
* VS build/run cycle works, with slightly awkward requirement to always build all
* Update manifest
* Plugin template fixes
* Minor adjustments
* Build install as part of build command, instead of separately
* Test cleanup
* Update Linux test for adjusted generated CMake approach
* Plugin test typo fix
* Add missing stub file for project test
* Add a constant for VS generator
