TX Text Control .NET Server

Linux

Topic

An application that works on Windows can still fail on its first Linux server, because Linux differs in what it installs, how it names files and how services start. TX Text Control .NET Server runs on Linux with the Core engine, and most failures there involve that engine or its Document Editor backend. Containers have a page of their own: Docker.

Check What Runs on the Server

With the application running as a systemd service, as Ubuntu sets it up, collect the evidence first:

  1. Follow the log of the service:

    sudo journalctl -fu kestrel-myapp.service
    

    A backend that has started logs Started TXTextControl.Web.Server.Core with Process ID, then Starting TCP listener on port 4283, and for each editor that connects Starting web editor worker process with connection ID.

  2. List the ports that are open:

    sudo ss -ltnp
    

    The backend listens on 127.0.0.1:4283 and the application on the port of Kestrel, for example 127.0.0.1:5000.

Verify the Deployment describes the output of a working server.

The Application Uses the Classic Engine

The application references TXTextControl.TextControl.ASP.SDK or TXTextControl.Web.DocumentViewer.Classic, which work on Windows only. Only the Core engine runs on Linux; replace the packages as The Classic Engine Doesn't Run Outside Windows describes.

The Distribution Is Too Old or Uses musl

The application runs on an older distribution, such as Debian 11, and fails when it loads the engine.

The native libraries of the Core engine need glibc 2.34 or later and a libstdc++ with GLIBCXX_3.4.29, which Debian 11 doesn't provide. Run the application on a current distribution, such as Ubuntu or Debian, with the packages libc6, libstdc++6 and libgcc-s1 installed. Processor Architecture and C Library lists the requirements. Alpine Linux, ARM64 processors and other unsupported platforms are covered in The Processor or the Operating System Isn't Supported.

The Process Ends When It Creates a PDF

The application process ends without an error message as soon as ServerTextControl creates a PDF document, and the Document Editor closes its connection when it exports a PDF document.

TX Text Control converts character sets with the gconv modules of glibc in /usr/lib/x86_64-linux-gnu/gconv, and they are missing. Check that the folder exists and contains the modules; on Debian 13, they belong to the package libc6. System Files explains them, and The Container Stops When It Creates a PDF covers chiseled container images.

The Backend Logs an Invalid Culture Identifier

For each editor that connects, the backend logs:

en is an invalid culture identifier.

.NET runs in globalization-invariant mode, because the ICU libraries are missing or DOTNET_SYSTEM_GLOBALIZATION_INVARIANT is set to true. Install ICU, or use an image that contains it, such as 10.0-noble-chiseled-extra, and remove the variable from the environment of the application. System Files describes the images.

The Backend Can't Start the dotnet Command

The application ends at startup with:

Error starting TXTextControl.Web.Server.Core: An error occurred trying to start process 'dotnet'

The backend and its worker processes are started with the dotnet command, which an application started through its own executable, or published self-contained, doesn't provide. Start the application with dotnet, for example with ExecStart=/usr/bin/dotnet /var/www/myapp/MyApp.dll in the systemd unit, or add the folder of the dotnet command to the search path of the service. .NET Runtime describes what the backend needs.

The Application Ignores appsettings.json

Settings from appsettings.json aren't applied, for example the address or port of the Document Editor backend, which then listens on all network interfaces again.

ASP.NET Core reads the file from the working directory of the process. Set the working directory of the service to the application folder, for example WorkingDirectory=/var/www/myapp in the systemd unit, and restart the service. Run the Application as a systemd Service shows the complete unit.

The Account Has No Access to the Files

The application or the backend can't read its files, or the backend can't write its log.

The account that runs the service, which the backend and its worker processes share, needs read access to the whole application folder, and write access to the log folder of the backend if you set LogTarget to File. Give the account the application folder, for example with sudo chown -R www-data:www-data /var/www/myapp. Files and Permissions lists what the account needs.

A File That Exists Isn't Found

A file is in the application folder, but TX Text Control behaves as if it were missing.

Linux file names are case-sensitive, and TX Text Control looks for some files by their exact names:

  • The Fonts folder. A folder named fonts isn't found. See The Default Font Installation Failed.
  • The configuration file of the backend. The backend reads TXTextControl.Web.Server.Core.config.json only in exactly this spelling. When it reads the file, it logs Successfully read config file 'TXTextControl.Web.Server.Core.config.json'.
  • Images in templates. Templates can reference images by Windows paths, such as C:\Users..., that don't exist on the server. See Images Are Missing After Loading.

Rename the file or folder to the exact name, or use the one from the package.

A Feature of the Windows Version Is Missing

A feature that the application used on Windows fails or has no effect on Linux.

The Core engine and the cross-platform backend differ from the Classic engine on Windows. Not Available on Linux lists the differences, among them: