Catch configuration mistakes earlier
Validation is cheaper before packaging than after a failed build or broken installer test.
FSS Analyzer validates the project while it is still lightweight editable text. In v3 that includes the canonical project type, so Application, Office Add-in and QGIS Plugin rules can be checked before entering their build backend.
Validation is cheaper before packaging than after a failed build or broken installer test.
The analyzer can report configuration that conflicts with specialized Office Add-in or QGIS Plugin semantics.
Application supports every build family while Office/QGIS intentionally use MSI and Bundle.
Analyze migrated FSS before the first build and review anything the importer could not map safely.
FSS remains plain text, so findings point to a project you can inspect, version and edit.
The goal is to make the project trustworthy before the heavier backend stages begin.
| Step | Action |
|---|---|
| 1 | Create, edit or import the FSS. |
| 2 | Normalize and identify its ProjectType. |
| 3 | Run FSS Analyzer and review errors/warnings. |
| 4 | Build one of the targets valid for that project. |
| 5 | Physically test install, upgrade and uninstall where applicable. |
If you used the ISS → FSS importer, analyze the converted project before relying on it for release packaging.
Office Add-in and QGIS Plugin projects have constraints that should be caught before invoking MSI/Bundle.
No. It validates project configuration; generated installers still require real install/uninstall testing.
Yes. It is especially useful after ISS migration and specialized project import.
Yes. InstallerLab v3 exposes headless analysis through InstallerLab --cli analyze project.fss.
FSS Analyzer keeps project validation close to the same editable file used by the GUI, CLI and build backends.