...
Location | Purpose |
|---|---|
| Executables and supporting libraries (read-only after install) |
| User-facing content: solutions, exchange folder, screenshots, trace logs (default) |
| Machine-scoped operational data: service state, cache (new installs)Optional location for operational data when configured for enterprise deployments |
Full layout reference: Installation Folders and Utilities Reference.
...
Service install options:
- Designer UI — Solution Center has a button to install Runtime → Startup has an AutoStartup button that installs the runtime as a serviceWindows Service
- Command-line — scripted install with elevated PowerShell (see Runtime Startup Reference)use
TManageServices.exe(located in the product root folder) from an elevated shell
Example: install the runtime as a Windows Service for a specific solution, unattended:
| Code Block | ||
|---|---|---|
| ||
cd "C:\Program Files\Tatsoft\FrameworX"
.\TManageServices.exe /installtstartup `
/solution:"C:\Users\Public\Documents\FrameworX\Solutions\Plant1.tproj" `
/silent
# Uninstall later
.\TManageServices.exe /uninstalltstartup /solution:"Plant1" /silent |
TManageServices.exe also handles TWebServices, TSecureGateway, TMQTTBroker, THardkey, and RuntimeMCPHttp. Run TManageServices.exe /? for the full command list. The /silent flag makes it script-friendly: it never pauses for input and returns a non-zero exit code on failure. Full reference: Runtime Startup Reference.
Run the service under a dedicated domain account where possible. The account needs:
...
The runtime writes trace logs by default to C:\Users\Public\Documents\FrameworX\TraceLogs\. New installs can use C:\ProgramData\Tatsoft\FrameworX\Logs\ instead — recommended for enterprise deployments because it matches Windows conventions for operational data and is automatically scanned by most log-collection agents The location is configurable per solution via Solution Settings; enterprise deployments typically relocate it under ProgramData so it's picked up by Windows-standard log collectors (Splunk forwarder, Datadog agent, Azure Monitor, ELK).
Install logs are written to the path specified by /LOG= during silent install, or to %TEMP%\Setup Log YYYY-MM-DD.txt for interactive installs.
...
Service lifecycle events
Windows logs basic service ( start, stop, unexpected shutdown, license failure) are written to the Windows Application and unexpected termination events for every installed FrameworX Windows service to the System event log under source FrameworX. Use this channel for integration with Service Control Manager. SCOM, Azure Monitor, Datadog, or any PRTG, and other Windows-native monitoring tooltools pick these up automatically without any custom configuration — point your alerts at the service name (for example, TStartup-<SolutionName>).
Application-level events (solution load failures, license errors, module exceptions) are written to the runtime TraceLogs. When an Event Log entry indicates a service failed to start, the root cause detail is in the most recent TraceLog file.
Runtime System Monitor
The built-in System Monitor exposes live metrics on tags, modules, memory, and client sessions. See Runtime System Monitor Reference and Runtime Diagnostics Reference.
...
- Back up the solution folder (
C:\Users\Public\Documents\FrameworX\Solutions\) - Back up the historian database (if external)
- Stop the runtime service gracefully
- Run the installer with silent switches
- Start the service and verify via System Monitor and Event Logthe Windows System event log
6. Uninstall
Uninstall from Programs & Features or silently:
...
The uninstaller removes the installed executables, the Windows Service registration, and the registry entries. User content under C:\Users\Public\Documents\FrameworX\ is preserved — remove manually if you want a fully clean uninstall.
To remove only the installed Windows services (without removing the product files), use:
| Code Block | ||
|---|---|---|
| ||
cd "C:\Program Files\Tatsoft\FrameworX" .\TManageServices.exe /removeallservices /silent |
7. Secure
Production deployments should follow the hardening checklist. Topics include TLS configuration, authentication (local users, Windows authentication, Active Directory), role-based access control, secrets storage, audit logging, and network segmentation.
...
- SCCM / Intune — package the silent installer as an application deployment with the switches shown in section 2. Use exit code
3010as a soft-reboot signal. - PowerShell DSC / Ansible / Chef — wrap
Start-Processwith the silent switches and check exit codes for the product installer; useTManageServices.exe /silentfor service install/uninstall steps. - Solution deployment — copy the
.dbslnsolution file to the target server's Solutions folder, then start runTManageServices.exe /installtstartup /solution:"<path>" /silentto install the runtime as a service. Solutions are self-contained. - Bulk uninstall — call
unins000.exewith silent switches across a fleet, orTManageServices.exe /removeallservices /silentto clean services only.
9. Troubleshoot
Symptom | First place to look |
|---|---|
Service won't start | Windows Event Log (Application System event log (source |
Port conflict |
|
License error | Event Log source |
Client can't connect to runtime | Firewall rule on runtime port, |
Web client blank / auth error | TLS certificate validity, browser console, Web Server Configuration Reference |
Database connection fails | Service account permissions, connection string, firewall rule to DB server |
...
When opening a support ticket, collect: Event Log entries (Application log, source FrameworX), the most recent TraceLog file, the install log, the output of Get-Service for the runtime service, the relevant Windows System event log entries for the service, and the solution build number.
...
- Container Deployment Reference — Docker and Kubernetes
- Linux Deployment Reference — .NET 8 on Linux servers and edge devices
- Redundancy Reference — primary/secondary runtime pairs
- SecureGateway Services Reference — multi-site communication routing
- Mobile App — mobile client deployment
11. Remote management via SolutionCenter API
From 10.1.5 GA, the recommended pattern for managing many FrameworX installations from a central place is the SolutionCenter API — a JWT-authenticated REST surface that every installation exposes on port 10108 (TWebServices). Central tools call it directly; bulk fan-out happens at the orchestration layer (Ansible, PowerShell DSC, custom dashboards) rather than per-machine WinRM or shipped agents. Surface covers solution lifecycle (list/run/stop), file ops, license activation, machine settings, and runtime connection inspection.
Activation-gated default-OFF in 10.1.5 — operators must explicitly enable per installation; see SolutionCenter API Reference for the activation procedure, scope model, endpoint catalog, and OpenAPI 3.1 document URL.
The product-install-time and service-lifecycle patterns from sections 2 and 8 above (silent installer, TManageServices.exe, SCCM / Intune / PowerShell DSC) are still the right tools for the install + service-registration layer of a fleet rollout. The SolutionCenter API operates one layer above — once installations exist, it manages what runs on them.