# SBOMs — Infragistics Ultimate UI for WinForms 26.1

WinForms ships on two runtimes via **different delivery mechanisms**, so there are **two SBOMs**
(CycloneDX 1.6, JSON):

| File | Runtime | Delivery | Components |
|---|---|---|---|
| `infragistics-winforms-dotnet-26.1.27.cdx.json` | .NET (net8/9/10-windows) | NuGet | 64 (62 first-party + 2 third-party) |
| `infragistics-winforms-netfx-26.1.20261.27.cdx.json` | .NET Framework (net472) | Installer | 142 (140 product + 2 third-party) |

## .NET SBOM (NuGet)

Authored from the delivered versionless nupkg set
(`Infragistics_WinForms_20261_NuGetPackages_VersionFree`, 62 packages, package version **26.1.27**),
exactly like the WPF SBOM: `pkg:nuget` PURLs, Infragistics EULA license, SHA-256/512 of each `.nupkg`,
shipped-TFM properties. Third-party is just **`System.Formats.Nrbf` 9.0.5** and
**`System.Text.Encoding.CodePages` 4.5.1** (both MIT); .NET runtime facades are framework-provided and
not enumerated.

## .NET Framework SBOM (installer)

.NET Framework is **not on NuGet** (installer-only; NuGet packaging is planned). There is no package
manifest, and the only 26.1 material is the release build's staging folder, which is polluted with
build/test/installer tooling. The ship-set was therefore derived as follows:

- **Product = 140 assemblies**: every Infragistics assembly in the release build **except** the
  `Infragistics.ApiGenerator` build tool. Versions and SHA-256/512 hashes are read from the PE files.
  Identity is `pkg:generic` (these are installer-delivered, not NuGet-published).
- **Third-party = 2 assemblies, chosen by evidence, not by guessing.** A reflection-only
  **assembly-reference analysis** of every Infragistics assembly showed that the only bundled
  third-party assemblies actually referenced by product controls are:
  - `Microsoft.AnalysisServices.AdomdClient` (referenced by the OLAP data provider)
  - `Microsoft.Ink` (referenced by `UltraWinInkProvider.Ink17`)
- **Excluded**: everything in the staging folder that no Infragistics product assembly references —
  Roslyn (`Microsoft.CodeAnalysis.*`), SpecFlow/`DataFireTesting`/VS test, SQL SMO (`Microsoft.SqlServer.*`),
  WiX/installer custom actions, `Newtonsoft.Json`, `zxing`, `EGIS.ShapeFileLib`, `Ionic.Zip`, and the
  redistributed `System.*` facades. These are build/test/tooling artifacts of the staging folder, not
  product runtime dependencies.

> The staging folder physically contains ~87 non-Infragistics DLLs, but assembly-reference evidence
> shows all but two are unreferenced by the product. Absent an installer file manifest, direct
> assembly references are the strongest available signal for "what the product actually depends on."
> If an installer manifest becomes available, the .NET Framework ship-set can be reconciled against it.

## Validation (both)

Each BOM validates clean against the official CycloneDX `bom-1.6.schema.json` (+ spdx, jsf) and passes
sanity checks: all components carry a PURL, every first-party component has a license, every dependency
reference resolves, and no build/test/design/installer pollution leaked in.

## Notes

- The previous `CreateWFSbomAssemblies.bat` (Syft-over-DLL-folders) output is superseded: it produced
  only ~71 components with `pkg:github` *source-location* identities rather than real package/assembly
  components.
- Versions: the .NET **package** version is `26.1.27`; the assembly build stamp (used for the .NET
  Framework product version) is `26.1.20261.27`.
- Regenerate per release with the kit in `C:\SBOM\Scripts\winforms`.