TX Text Control is more than .NET assemblies: its engine consists of native libraries that must match the operating system and the processor architecture the application runs on. When they don't, or when a runtime they need is missing, the application fails as soon as the engine starts.

What the Packages Contain

Each SDK package brings the native libraries of the platforms it supports in its runtimes folder: TXTextControl.TextControl.Core.SDK for win-x64 and linux-x64, and TXTextControl.TextControl.ASP.SDK for win-x64 and win-x86. Package Overview describes the packages, and Publish for the Target Runtime how a runtime identifier selects the libraries that are published.

The Application Runs as a 32-Bit Process

An application with the Document Editor ends during startup with this message; under IIS, the site answers with the error 500.30:

The TX Text Control Web Server Core process requires a 64 bit environment. Please ensure that the application is running in a 64 bit environment.

The Core engine has native libraries for 64-bit processes only. The application runs as a 32-bit process, for example because it was published for win-x86, because the IIS application pool has Enable 32-Bit Applications set to True, or because Azure App Service runs the application in a 32-bit worker process.

Publish for a 64-bit runtime:
```
dotnet publish -c Release -r win-x64 --self-contained false
```
In the Visual Studio publish profile, set Target runtime to win-x64 or linux-x64.
Run the application in a 64-bit process of the host: see The Site Answers With Error 500.30 for IIS and The Application Doesn't Start on Windows for Azure App Service.

The Classic engine has native libraries for win-x86 as well, but the Document Editor backend requires a 64-bit process.

The Processor or the Operating System Isn't Supported

The application doesn't run on a Mac, on a server with an ARM64 processor, such as an AWS Graviton instance, or in an Alpine Linux container.

The packages contain native libraries for x64 processors on Windows and on Linux with the GNU C library (glibc) only. There are none for macOS, for ARM64 processors or for Linux distributions with the musl C library, such as Alpine. On Alpine, the application process ends when a document is created.

Run the application on x64 Windows or on an x64 Linux distribution with glibc, for example Ubuntu or Debian.
Choose x64 instance types, build agents and container base images. Tests that use ServerTextControl don't run on macOS or ARM64 build agents either.

Linux Requirements lists the requirements of Linux systems, and Processor Architectures those of all systems.

The Classic Engine Doesn't Run Outside Windows

An application that uses TXTextControl.TextControl.ASP.SDK or TXTextControl.Web.DocumentViewer.Classic is deployed to Linux or to a Linux container.

The Classic engine requires Windows. Its package contains native libraries for Windows only, and it can't be used on Linux or in Linux containers.

Replace TXTextControl.TextControl.ASP.SDK with TXTextControl.TextControl.Core.SDK. Both contain ServerTextControl in the TXTextControl namespace, so your code stays the same.
Replace TXTextControl.Web.DocumentViewer.Classic with TXTextControl.Web.DocumentViewer.
Follow the remaining steps in From Classic to Core, which covers fonts, formats and testing.
If the application has to load or save DOC files, which only Classic supports, keep it on Windows.

The Document Engine compares the two engines.

The Visual C++ Redistributable Is Missing

The application runs on a Windows server that has only the .NET runtime installed.

TX Text Control requires the Microsoft Visual C++ Redistributable for Visual Studio 2017, 2019 and 2022, in its x64 version, on Windows servers.

Install the x64 version of the Microsoft Visual C++ Redistributable for Visual Studio 2017, 2019 and 2022 on the server.

What a Windows Server Needs lists everything to install.

Create Returns False

ServerTextControl.Create returns false, often only after the application has run for days. An instance that is used anyway throws this message:

The TXTextControl object must have been completely loaded to use this method.

On Windows, a new instance can't be created when no new window handle can be created. Windows limits a process to 10,000 USER handles and 10,000 GDI handles, and instances that are never disposed keep theirs. This is the most common reason why Create returns false.

Create every ServerTextControl in a using block, so that it's disposed and releases its handles.
Check the return value of Create, and don't use the instance when it's false.
Count the instances your application creates and disposes, as Dispose Every ServerTextControl shows.

There is no need to restart IIS or the worker process: dispose the instances, and their handles are released. The blog article Diagnostics: When Calling ServerTextControl.Create() Failed counts the handles of a process.

The 64-Bit .NET Runtime Is Not Found

An application with the Document Editor ends during startup with this message:

The 64 bit .NET runtime was not found. Please ensure that the 64 bit .NET runtime is installed on this machine.

The Document Editor backend TXTextControl.Web.Server.Core is a .NET application of its own, which the hosted service DocumentEditorWorkerManager starts as a separate process. On Windows, the manager looks for the 64-bit .NET runtime of the machine and starts the backend with it.

Install the .NET runtime in its x64 version. On a server with IIS, install the .NET Hosting Bundle, and don't install it with the option OPT_NO_RUNTIME=1, which leaves out the runtime.
On Linux, make sure that the dotnet command can be found by the application. See .NET Runtime in Linux Requirements.

Prepare the Server describes the installation on a Windows server.

Native Library / Runtime Errors