Installation Folders and Utilities Reference

Understand folder structure and built-in utilities.

Reference → Installation → Folders | Licensing | Updates | SecureGateway | Web Server

Executables Installation

Default location: C:\Program Files\Tatsoft\FrameworX\

Custom paths can be selected during installation.

User Document Folders

Created on first execution under <User>\Documents\FrameworX\:

Public Document Folders

Created under C:\Users\Public\Documents\FrameworX\:

Log Locations

The runtime and supporting services write trace logs to a configurable location. The default is user-visible under Public\Documents, and enterprise deployments can relocate to ProgramData:

Install logs are written separately:

• Silent install: path specified by /LOG=<path> command-line switch
• Interactive install: %TEMP%\Setup Log YYYY-MM-DD #xxx.txt

Windows Event Log: Windows logs basic service lifecycle events (start, stop, unexpected termination) to the System event log under source Service Control Manager for any installed FrameworX Windows service. SCOM, Azure Monitor, Datadog, and similar Windows-native monitoring tools pick these up automatically without any custom configuration. Application-level events (solution load errors, license failures, module exceptions) are written to the runtime TraceLogs — check there for detail when an Event Log entry indicates a failed start.

For the enterprise deployment workflow, see IT Deployment RunBook.

Log File Size and Retention

Each runtime process (TServer, TStartup, TRunModule, TRichClient) can cap the size of its active log file and limit how many daily archives are kept. Both settings are optional and read from the process's JSON configuration file (<ProcessName>.json — for example TServer.json) under appSettings.Logging. When the file or the section is absent, the default behavior applies: no size limit, and every daily archive is kept.

Example TServer.json:

{
  "appSettings": {
    "Logging": {
      "MaxFileSizeMB": 50,
      "KeepAllZips": false
    }
  }
}

These settings apply only to the trace/execution log files described under Log Locations above, and only when logging is enabled for the process (the SaveLog startup setting). Each process reads its own JSON file, so limits can differ per process.

Installed Utilities

The Utilities folder holds the stand-alone utilities below. Other command-line tools ship in the product root or in the versioned fx-10 folder, as shown in the Location column.

Windows Service management and the AI/MCP listeners have their own reference pages:

• TManageServices.exe (product root) installs and uninstalls the FrameworX Windows services (TStartup, TWebServices, TSecureGateway, TMQTTBroker, THardkey, RuntimeMCPHttp), including /removeallservices. See TManageServices CLI.

• DesignerMCPHttp.exe, RuntimeMCPHttp.exe and ConsoleMCPHttp.exe (fx-10\net10.0\) expose the AI integration listeners. See MCP and Claude Setup and AI Designer Connector.

AutoStartClient.exe

AutoStartClient starts a client automatically once a runtime server is ready to accept it. The utility polls the configured server and launches the configured action as soon as that server can actually serve a client, which avoids the common failure of a Windows Startup-folder shortcut firing before the runtime is ready.

AutoStartClient covers the client side only. The runtime itself starts at boot as a Windows Service: see Runtime Startup Reference, Enabling AutoStartup.

The Windows Startup folder only runs at logon. On a station that sits without a logged-on user, configure Windows automatic logon as well, otherwise the client never starts.

Settings are read from AutoStartClient.exe.config, in the same folder as the executable. For that reason the utility is started through a shortcut, never a copy of the executable: a copy placed elsewhere does not find its configuration file.

Run AutoStartClient at logon

1. Open the fx-10\Utilities folder of the FrameworX installation (by default C:\Program Files\Tatsoft\FrameworX\fx-10\Utilities), right-click AutoStartClient.exe and select Create shortcut. If Windows offers to place the shortcut on the desktop instead, accept.

2. Press Win+R, type shell:common startup and press Enter. This opens the Startup folder for all users of the computer. Moving a file into it requires administrator rights; for a single user, use shell:startup instead.

3. Move the shortcut into that Startup folder.

4. Right-click the shortcut, select Properties, and set Start in to the Utilities folder from step 1.

5. If nobody logs on to the station, configure Windows automatic logon, as described above.

To test it, sign out of Windows and sign in again: the AutoStartClient window opens, or its tray icon appears when hidden is set to true.

What each poll does

1. Checks whether a client is already running. Any process named in clientprocessnames counts — by default the Rich Client and the Smart Client — whatever started it, so the configured action is not invoked again while a client is on screen. This includes a Rich Client opened by the solution itself (the Displays module under Runtime → Startup): on that computer the utility then starts nothing. The utility also tells a client that is connected to a server from one that is merely running, so a client stopped on an error dialog is not counted as a working client.

2. Checks whether the server is ready for a client, on each configured address in turn: the address answers, the runtime reports that it has finished starting, and — on a redundant pair — that node reports it is the active one. A node that is up but running as standby refuses every client, so it is not used until it takes the active role.

3. Starts the configured action for the first address that passes: batch / batch2, or url / url2. A batch file is started without a console window, so nothing flashes over the operator screen.

Reading the status window. With hidden set to false, the utility lists each step. While the runtime is not up yet it shows Waiting remote server starts (127.0.0.1:3101)... [127.0.0.1:3101: not accepting connections]; once a client is up it shows Client is running and connected.... A configuration value it cannot use is reported in a dialog when the utility starts.

A process guard in the batch file is no longer needed. Earlier versions invoked the configured action on every poll, and the common workaround was a tasklist check inside the .bat to stop clients accumulating. From 10.1.5e the utility performs that check itself and calls the action only when no client is running at all, so by the time the batch file executes there is nothing for the guard to find. It is redundant, not harmful, and leaving it in place changes nothing. Remove it or keep it as you prefer.

What the guard never did, in any version, was retry: a client stopped on a connection-error dialog is handled by recoverstuckclient, described below, not by anything in the batch file.

A client that stops responding. If a client is running but never establishes a connection, the utility reports it in its own message list and as a tray notification. By default it is then closed and replaced: only a client the utility itself started is ever closed, and only after stuckclienttimeout seconds with no connection, after which the next poll runs the full readiness check again before starting a new one. A viewer opened by an operator, or by any other tool, is reported but never closed. Set recoverstuckclient to false to have the utility report such a client and leave it in place, which means an unattended station stays on the error dialog until somebody dismisses it.

Which client to start

• Rich Client (recommended for unattended stations): set batch to a batch file that runs TRichClient.exe /ip1:<ServerIP> /port1:3101, as in the example below. Requires FrameworX installed on the station.

• HTML5 client: set url to http://<ServerIP>/html5. Nothing to install on the station.

• Smart Client: the client itself is not installed on the station; it needs .NET Framework 4.8 (see Client Types Reference). Through url, the browser opens it and asks for confirmation on every launch ("Do you want to open TSmartClient.application?"), so an unattended station stops on that dialog. Use batch instead, as described in Smart Client without the browser prompt below.

Smart Client without the browser prompt

Optional. Use this when a station runs the Smart Client and nobody is there to confirm the browser prompt. Instead of opening the Smart Client address in a browser, the batch file hands it straight to Windows ClickOnce, so no browser window and no prompt appear.

First the batch file. Create it yourself, for example as C:\FrameworX\StartSmartClient.bat:

@echo off
rundll32.exe dfshim.dll,ShOpenVerbApplication http://192.168.1.1:3101/TSmartClient.application?ip1=192.168.1.1^&port1=3101^&connectiontimeout=5^&userName=guest

• The address is the server's TSmartClient.application followed by the client parameters: ip1 and port1 for the server, connectiontimeout and userName. For a redundant pair add ip2 and port2, as in the Smart Client URL on Redundancy Reference.

• Write every & in the address as ^&. In a batch file a plain & ends the command, and the rest of the address is lost.

• To see the exact address your server hands out, open the Smart Client once through the browser and copy the TSmartClient.application download link.

• To check the batch file on its own, double-click it: the Smart Client opens with no browser window.

Then the matching AutoStartClient.exe.config:

<appSettings>
  <add key="ip" value="192.168.1.1"/>
  <add key="port" value="3101"/>
  <add key="url" value=""/>
  <add key="batch" value="C:\FrameworX\StartSmartClient.bat"/>
  <add key="timer" value="30"/>
  <add key="hidden" value="true"/>
</appSettings>

Leave url empty: the batch file replaces it. TSmartClient is already in the default clientprocessnames, so the utility recognizes the Smart Client as the running client and, with relaunchclient on, starts it again if it closes. The first time the Smart Client runs on a station, Windows may ask once to trust the application.

Custom Installation Paths

For Linux/Docker deployments, create custompaths.txt in installation folder:

MyDocuments=<folder>
CommonDocuments=<folder>
CommonApplicationData=<folder>

Typically points to memory areas outside Docker image for read/write access.

In this section...