Files
fleet/frontend
Allen Houchins 051d12718c Add JetBrains ReSharper as a Windows Fleet-maintained app (#50659)
**Related issue:** Resolves #50567

Adds JetBrains ReSharper as a Windows Fleet-maintained app (winget
`JetBrains.ReSharper`, version `2026.2.0.2`).

ReSharper is a Visual Studio extension rather than a standalone app, so
it does not follow the pattern of the other JetBrains FMAs (Rider,
PhpStorm, DataGrip, etc.), which are plain NSIS installers that take
`/S`. Reviewers should read the risks below before approving — a couple
of things can only be confirmed from a validator run.

## What's here

- `ee/maintained-apps/inputs/winget/resharper.json`
- `ee/maintained-apps/inputs/winget/scripts/resharper_install.ps1` /
`resharper_uninstall.ps1`
- Generated `ee/maintained-apps/outputs/resharper/windows.json` +
`apps.json` entry
- Icon (`Resharper.tsx`, website PNG, alphabetical `index.ts` entries),
generated from JetBrains' own brand asset

## Decisions that differ from the other JetBrains FMAs

**`use_display_version_for_patch` is omitted.** Every other JetBrains
winget input sets it, but the ReSharper manifest has no
`AppsAndFeaturesEntries`, so the ingester hard-errors with
`use_display_version_for_patch is set but no DisplayVersion found in
winget manifest`. The patch policy therefore compares against winget's
`2026.2.0.2`.

**Custom `exists_query` instead of `fuzzy_match_name`.** The prefix is
loose enough to match a possible per-VS-instance suffix, and excludes
the separate ReSharper C++ and ReSharper SDK products:

```sql
SELECT 1 FROM programs WHERE name LIKE 'JetBrains ReSharper%' AND name NOT LIKE 'JetBrains ReSharper C++%' AND name NOT LIKE 'JetBrains ReSharper SDK%' AND publisher = 'JetBrains s.r.o.';
```

**Install script detects Visual Studio.** It builds `/VsVersion` from
the instances `vswhere` reports and runs the installer with
`/Silent=True /PerMachine=True /SkipEtwService=True`:

- `/PerMachine=True` — the installer otherwise targets `%LocalAppData%`,
which under Fleet's SYSTEM context would land in the SYSTEM profile
instead of the developer's. The path is not configurable
([RSRP-428991](https://youtrack.jetbrains.com/issue/RSRP-428991)).
- `/SkipEtwService=True` — JetBrains documents that `EtwHostService.msi`
always raises a UAC prompt, so a fully silent install of every component
is not possible
([SUPPORT-A-3189](https://youtrack.jetbrains.com/articles/SUPPORT-A-3189)).
- It then waits for the uninstall registry entry (what osquery reads),
because the web bootstrapper can outlive its own exit code, and logs the
resulting ARP entries.

**Uninstall removes every matching entry**, since ReSharper registers
one per Visual Studio instance, using the defensive `UninstallString`
parser and appending `/Silent=True` rather than the NSIS `/S`.

Switches come from [JetBrains' silent install/uninstall
article](https://resharper-support.jetbrains.com/hc/en-us/articles/207241485-How-to-use-silent-install-and-silent-uninstall-of-ReSharper-via-Command-Line),
not guesswork.

## `unique_identifier` is provisional

`program_publisher` is verified — `JetBrains s.r.o.` is hard-coded next
to the ARP value names (`DisplayName`, `DisplayVersion`,
`UninstallString`, `Publisher`) in `JetBrains.Platform.Installer.exe`,
extracted from the installer.

The **DisplayName is not verifiable offline.** The winget URL is a
two-stage web bootstrapper: the 69 MB `.web.exe` contains
`JetBrains.Platform.Installer.Bootstrap.exe`, which downloads the
JetBrains dotUltimate installer, which downloads the product packages.
The ARP entry is written by that downloaded stage under
`Software\Microsoft\Windows\CurrentVersion\Uninstall\{GUID}`, with
`DisplayName` taken from a per-VS-host `PresentableName`. So `JetBrains
ReSharper` is a best-supported guess.

It can be confirmed from a validator run:
`cmd/maintained-apps/validate/windows.go` searches `programs` with a
loose `LOWER(name) LIKE '%…%'` on both the catalog name and
`unique_identifier`, and logs `Found app: '<DisplayName>' … Version:
<ver>` after running `MutateSoftwareOnIngestion`. That reveals both the
true DisplayName and the post-mutation version. The install script
prints the same information. **Expect a follow-up commit correcting
`unique_identifier` (and possibly the exists query) once that log
lands.**

## Risks

1. **Payload is not pinned.** The SHA covers only the 69 MB
bootstrapper; roughly 1.7 GB is fetched from `download.jetbrains.com` at
install time. JetBrains publishes only a `windowsWeb` download for
ReSharper, so there is no offline installer to point at. Install
duration may exceed script timeouts.
2. **Requires Visual Studio.** With no VS present the installer has
nothing to install, so the script exits 1 with a clear message.
`windows-latest` runners ship Visual Studio 2022 Enterprise, so
validation should be able to install.
3. **`/PerMachine=True` conflicts with pre-existing per-user installs.**
JetBrains states machine-wide mode "is not compatible with existing
installations in user profiles"; one must be removed first.
4. **`/SkipEtwService=True` omits the ETW host service**, so
dotTrace/dotMemory profiling integration is incomplete. This is the
documented tradeoff for an unattended install.
5. **Version reconciliation unconfirmed.** If the DisplayName ends in a
marketing version, the JetBrains name-based version mutation fires and
the validator's prefix check passes; a VS-suffixed name would instead
fall back to the registry `DisplayVersion`.

# Checklist for submitter

- [x] 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.
- [x] Timeouts are implemented and retries are limited to avoid infinite
loops

## Testing

- [x] `go test ./ee/maintained-apps/...` passes; both output JSON files
parse; generated SHA matches the winget manifest.
- [ ] QA'd all new/changed functionality manually — **not done.**
Install/uninstall need a Windows host with Visual Studio; relying on the
FMA Windows validator, which is also how `unique_identifier` gets
confirmed.


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **New Features**
  * Added ReSharper to the maintained Windows applications catalog.
* Added support for silent machine-wide installation and uninstallation.
* Added Visual Studio compatibility checks and installation failure
reporting.
  * Added a ReSharper icon for display in the software catalog.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
2026-08-07 12:16:17 -05:00
..
2026-07-28 15:01:48 +01:00
2026-07-15 19:35:27 -03:00
2026-07-28 15:01:48 +01:00

Fleet frontend

The Fleet frontend is a Single Page Application using React with Typescript and Hooks.

Table of contents

Running the Fleet web app

For details instruction on building and serving the Fleet web application consult the Contributing documentation.

Testing

Visit the overview of Fleet UI testing for more information on our testing strategy, philosophies, and tools.

To run unit or integration tests in ComponentName.tests.tsx, run yarn test -- ComponentName.tests.tsx. To test all Javascript components run yarn test.

QA Wolf manages our E2E test and will maintain the tests as well as raise any issues found from these tests. Engineers should not have to worry about working with E2E testing code or raising issues themselves.

For more information on how our front-end tests work, visit our frontend test directory.

Directory structure

Component directories in the Fleet front-end application encapsulate the entire component, including files for the component and its styles. The typical directory structure for a component is as follows:

└── ComponentName
  ├── _styles.scss
  ├── ComponentName.tsx
  |-- ComponentName.tests.tsx
  ├── index.ts
  • _styles.scss: The component css styles
  • ComponentName.tsx: The React component
  • ComponentName.tests.tsx: The React component unit/integration tests
  • index.ts: Exports the React component
    • This file is helpful as it allows other components to import the component by it's directory name. Without this file the component name would have to be duplicated during imports (components/ComponentName vs. components/ComponentName/ComponentName).

components

The component directory contains global React components rendered by pages, receiving props from their parent components to render data and handle user interactions.

context

The context directory contains the React Context API pattern for various entities. Only entities that are needed across the app has a global context. For example, the logged in user (currentUser) has multiple pages and components where its information is pulled.

interfaces

Files in the interfaces directory are used to specify the Typescript interface for a reusable Fleet entity. This is designed to DRY up the code and increase re-usability. These interfaces are imported in to component files and implemented when defining the component's props.

Additionally, local interfaces are used for props of local components.

layouts

The Fleet application has only 1 layout, the Core Layout. The Layout is rendered from the router and are used to set up the general app UI (header, sidebar) and render child components. The child components rendered by the layout are typically page components.

pages

Page components are React components typically rendered from the router. React Router passed props to these pages in case they are needed. Examples include the router, location, and params objects.

router

The router directory is where the react router lives. The router decides which component will render at a given URL. Components rendered from the router are typically located in the pages directory. The router directory also holds a paths file which holds the application paths as string constants for reference throughout the app. These paths are typically referenced from the App Constants object.

services

CRUD functions for all Fleet entities (e.g. report) that link directly to the Fleet API.

styles

The styles directory contains the general app style setup and variables. It includes variables for the app color hex codes, fonts (families, weights and sizes), and padding.

templates

The templates directory contains the HTML file that renders the React application via including the bundle.js and bundle.css files. The HTML page also includes the HTML element in which the React application is mounted.

test

The test directory includes test helpers, API request mocks, and stubbed data entities for use in test files. See the UI testing documentation for more on test helpers, stubs, and request mocks.

utilities

The utilities directory contains re-usable functions and constants for use throughout the application. The functions include helpers to convert an array of objects to CSV, debounce functions to prevent multiple form submissions, format API errors, etc.

Patterns

The list of patterns used in the Fleet UI codebase can be found in patterns.md.

Storybook

Storybook is a tool to document and visualize components, and we use it to capture our global components used across Fleet. Storybook is key when developing new features and testing components before release. It runs a separate server exposed on port 6006. To run this server, do the following:

  • Go to your root fleet project directory
  • Run make deps
  • Run yarn storybook

The URL localhost:6006 should automatically show in your browser. If not, visit it manually.

Running Storybook before implementing new UI elements can clarify if new components need to be created or already exist. When creating a component, you can create a new file, component.stories.tsx, within its directory. Then, fill it with the appropriate Storybook code to create a new Storybook entry. You will be able to visualize the component within Storybook to determine if it looks and behaves as expected.