<!-- Add the related story/sub-task/bug number, like Resolves#123, or
remove if NA -->
**Related issue:** Resolves#50653
Adds **Visual Studio 2022 Community, Professional, and Enterprise** as
Windows Fleet-maintained apps. customer-universitas needs all three
editions.
## What's here
- Three input files, one per edition, each pointing at its own winget
package
(`Microsoft.VisualStudio.2022.{Community,Professional,Enterprise}`, all
at `17.14.37`).
- A shared install script (`visual_studio_2022_install.ps1`) — the
downloaded file is a ~4 MB bootstrapper, not the IDE. The real multi-GB
payload downloads from Microsoft *during* the install script, so install
time depends on the host's network speed and counts against Fleet's
1-hour software-install timeout. `--wait` is required or the
bootstrapper forks the real install to a background process and returns
almost immediately.
- Three uninstall scripts (one per edition) that resolve the install
path via `vswhere.exe -products
Microsoft.VisualStudio.Product.<Edition>` and call `vs_installer.exe
uninstall --installPath <path> --quiet --norestart --wait`, since VS has
no normal `UninstallString`.
- Both scripts map winget's documented `3010`/`1641` (reboot
pending/initiated) to a successful exit, and fail clearly on
`1001`/`1618` (another VS Installer operation already running).
- Default install ships the bare IDE shell (no `--add` workloads) —
matches plain `winget install` behavior, per the issue's own conclusion
that this needs no special-casing.
- Icons: no scriptable source (no Windows host to extract the real
per-edition `.exe` icon, and Microsoft's own download pages don't expose
one) turned up distinct Community/Professional/Enterprise badge art, so
all three currently use the same public Visual Studio mark ([Wikimedia
Commons](https://commons.wikimedia.org/wiki/File:Visual_Studio_Icon_2022.svg),
marked public domain). **Flagging for #g-software Product Designer** to
swap in the real per-edition badges if we have them.
## What I could not verify (no Windows host in this environment)
- `unique_identifier`/publisher (`Visual Studio
Community/Professional/Enterprise 2022`, publisher `Microsoft
Corporation`) are taken from the winget locale manifest, not confirmed
against a live registry entry.
- The version-string quirk the issue calls out: winget's
`AppsAndFeaturesEntries.DisplayVersion` is `"17.14.37 (July 2026)"`, not
a clean version. I deliberately did **not** set
`use_display_version_for_patch` — feeding that non-numeric string in as
the patch target would break `version_compare` ordering across future
version bumps (see the comment in `ingester.go`). Instead the patch
policy compares against the plain winget `PackageVersion` (`17.14.37`),
same as most winget FMAs. This should hold up if `version_compare` reads
leading numeric-dot segments and ignores the trailing text, but I can't
confirm that against real `programs.version` output without a host.
- Whether `vs_installer.exe` actually honors `--wait` for `uninstall`
the way the bootstrapper does for `install` — Microsoft's own docs say
`--wait` "can only be passed into the bootstrapper; the installer
(setup.exe) doesn't support it," which is in tension with the exact
command this issue asked for and what I've seen used in the wild. Worth
watching in validation logs.
- End-to-end install timing on a normal (non-datacenter) connection,
within the 1-hour timeout.
# Checklist for submitter
- [ ] Changes file added for user-visible changes in `changes/`,
`orbit/changes/` or `ee/fleetd-chrome/changes`.
<!-- Not added — no precedent for a changes file on FMA-addition PRs
(e.g. #50553, TeamViewer Host). -->
- [ ] Input data is properly validated, `SELECT *` is avoided, SQL
injection is prevented (using placeholders for values in statements), JS
inline code is prevented especially for url redirects, and untrusted
data interpolated into shell scripts/commands is validated against shell
metacharacters.
- [ ] Timeouts are implemented and retries are limited to avoid infinite
loops
- [ ] If paths of existing endpoints are modified without backwards
compatibility, checked the frontend/CLI for any necessary changes
## Testing
- [x] `apps.json` is valid JSON with descriptions filled in for all
three editions
- [x] Generator output reviewed: exists/patched queries, SHA256 (matches
the live winget manifest), installer URLs
- [x] `go build`/`go test ./ee/maintained-apps/...` pass; no shared
ingester/validator code changed
- [ ] FMA validator: install → detect → uninstall on a Windows host —
**pending, needs a Windows host**
- [ ] QA'd all new/changed functionality manually — **pending, same
reason**
## FMA-specific (from issue #50653's acceptance criteria)
- [x] Edition scope decided and recorded on the issue (all three:
Community, Professional, Enterprise)
- [x] Input added under `ee/maintained-apps/inputs/winget/`
- [x] Custom install script handles `3010`/`1641` as success and fails
clearly on `1618`/`1001`
- [x] Custom uninstall script resolves the install path via `vswhere`
and calls `vs_installer.exe uninstall`
- [ ] Identity fields verified against a real installed host — **not
yet, see above**
- [ ] Patch policy verified against actual `programs.version` — **not
yet, see above**
- [ ] Install verified end to end within the 1-hour timeout on a
normal-speed connection — **not yet**
- [ ] Passes the FMA validator: install → detect → uninstall — **not
yet**
- [x] Icon exists (shared placeholder mark across all three editions —
flagged for PD)
No shared/ingester/validator code changed.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Added Visual Studio 2022 Community, Professional, and Enterprise
editions to the software catalog.
- Added support for installing and uninstalling each edition with quiet
execution, installation detection, error handling, and reboot handling.
- Added version 17.14.37 metadata and update detection.
- Added Visual Studio branding and edition-specific icons throughout the
software interface.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Allen Houchins <allenhouchins@mac.com>
