* Check for bad characters in path on Windows build
* Doc comments
* Fix formatting
* Commenting/formatting
* Link to issue in comment
* Comments, formatting
* Global var rename
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
Previously developers had to edit their `Runner.rc` file to update their executable's version information. Now, version information will automatically be set from `flutter build`'s arguments or the `pubspec.yaml` file for new projects.
Addresses https://github.com/flutter/flutter/issues/73652
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.
When desktop support is not present in an existing project, certain
flutter tool commands raise an error that direct the user to
documentation on how to add desktop support to an existing Flutter
project. In a recent revamp of the webside, the URL was very slightly
changed (flutter.dev -> docs.flutter.dev).
This updates the error message to output the new URL.
Issue: https://github.com/flutter/flutter/issues/94398
This adds avoid_dynamic_calls to the list of lints, and fixes all instances where it was violated.
Importantly, this lint is NOT turned on for flutter/packages/test, because those changes are happening in another PR: #84478
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
Adds the rest of the scaffolding for building a UWP application. The actual build functionality needs to be implemented, but could use buildWindows as an example (if it is going through cmake)
#14967
