48 lines
3.3 KiB
Markdown
48 lines
3.3 KiB
Markdown
# Architecture summary
|
|
|
|
## Project architecture
|
|
|
|
```text
|
|
All_Serv_InstallUpdater.exe (independent repository / updater)
|
|
-> starts local All_Serv_Install.exe
|
|
|
|
All_Serv_Install.exe (independent repository / visible installer and synchronizer)
|
|
-> starts configured P_Serv_Starter.exe
|
|
|
|
P_Serv_Starter.exe (separate repository / Plant bootstrap)
|
|
-> generates local _app_netload.lsp
|
|
-> copies launcher_starter.lsp
|
|
-> starts configured local start_plant_3d.bat
|
|
|
|
All_Serv_Load.exe (independent repository)
|
|
-> separate historical/alternate loader; no source dependency edge to the above
|
|
```
|
|
|
|
There are no ProjectReference edges between the three projects beneath `C:\dev\launcher\git`; each is its own one-project solution. `P_Serv_Starter` is a fourth independent repository selected by configuration, not a project reference. This explains why a user can experience one product despite multiple executables: the updater can hand off to the visible installer, which synchronizes selected applications and delegates Plant startup to a hidden bootstrap. Actual deployed shortcut/entrypoint evidence was not present, so the updater's use in a specific installation remains `INFERRED`.
|
|
|
|
## Roles and status
|
|
|
|
| Project | Output | Role | Status | Evidence |
|
|
|---|---|---|---|---|
|
|
| All_Serv_Install | WinExe | visible catalog UI, synchronizer and configured process launcher | ACTIVE_PRIMARY | Form1 startup and copy/Process.Start code |
|
|
| All_Serv_InstallUpdater | WinExe | installer self-updater then handoff | ACTIVE_UPDATER | Form1_Load MD5/copy/start code |
|
|
| All_Serv_Load | WinExe | independent alternate/historical loader | UNKNOWN | independent Form1 and 2019 batch script; no current deployment proof |
|
|
| P_Serv_Starter | Exe | Plant session bootstrap | ACTIVE_BOOTSTRAP | selected in installer XML; writes loader and starts batch |
|
|
|
|
## Runtime chain
|
|
|
|
The confirmed chain ends at execution of the local Plant start batch. The gap between that batch and `launcher_starter.lsp` automatic loading is `UNKNOWN`: no local batch, `acaddoc.lsp`, or Applications files were found. Once `launcher_starter.lsp` runs, all following load steps are source-confirmed.
|
|
|
|
## Answers to the requested questions
|
|
|
|
1. The three launcher projects are independent WinForms executables: installer, updater and alternate loader.
|
|
2. `All_Serv_Install` creates the confirmed visible catalog UI.
|
|
3. Three EXE artifacts are declared by the launcher repositories; P_Serv_Starter adds one external bootstrap EXE.
|
|
4. No launcher project is a class library; `launcher_starter.lsp` is a copied runtime content artifact.
|
|
5. Updater/helper/bootstrap behavior is confirmed in source; actual installed-process count is unknown.
|
|
6. Plant launch is delegated by `All_Serv_Install` to configured `P_Serv_Starter.exe`; the bootstrap starts a local batch. A current Plant executable/profile/argument string is not proven.
|
|
7. `app_netload.lsp` and `OrthoLoader.dll` are connected through P_Serv_Starter generated LISP and installer plugin metadata.
|
|
8. The installer synchronizes corporate application folders to a local Applications cache; it does not load P_Rec_Annot directly.
|
|
9. No source proof warrants modifying LAUNCHER for the new plugin yet. First validate one local entry assembly through the established catalog/bootstrap contract in a non-production pilot.
|
|
|