Azure
Four settings decide whether TX Text Control .NET Server runs on Azure App Service: the platform, the target runtime of the published application, Web sockets and session affinity. When an application that works locally fails after it's published, check these first, on Windows as well as on Linux; Azure in the Deployment Guide describes the setup.
Read the Logs of the App Service
Stream the log of the application with az webapp log tail while you reproduce the problem; on Linux, turn on the log of the container first. The application passes the messages of the Document Editor backend to its logging, so a started backend shows the line Starting TCP listener on port 4283. Check the Application on Linux and Check the Application on Windows show the commands, the messages you can ignore and how to list the installed runtimes.
The Editor Doesn't Connect on Windows
The page loads, but the Document Editor shows:
Can't connect to the server.
Please refresh the website to re-connect.
Web sockets is off, which is the default for App Service on Windows; Linux apps always have WebSockets enabled. Switch Web sockets on in the General settings of the App Service, or with az webapp config set --web-sockets-enabled true, as step 7 of Create the App Service and Publish From Visual Studio shows. If the editor still doesn't connect, see WebSockets.
The Application Doesn't Start on Windows
The application ends during startup. The log shows:
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 application runs in a 32-bit worker process, or it was published for win-x86. Choose the Basic tier or higher, because the Free and Shared tiers run 32-bit processes only, set Platform to 64 Bit and publish for win-x64, as Before You Create the App Service and the steps after it describe. The Application Runs as a 32-Bit Process explains the message.
Applications built from articles for version 33.0 start the backend with a hosted service of their own. Replace it with the package TXTextControl.Web.DocumentEditor.Backend, which starts the backend with the 64-bit .NET runtime; see From the Old Document Editor Backend to the Backend Package.
The Application Doesn't Start on Linux
The application doesn't start on App Service on Linux, although it runs on Windows.
The application was published for a Windows runtime, such as win-x64, so the publish output contains only the native libraries for Windows. Publish with the target runtime linux-x64, as Azure App Service on Linux does. If the application still doesn't start, see Linux and Native Library / Runtime Errors.
The Classic Engine Fails in the Windows Sandbox
An application with the Classic engine, from the package TXTextControl.TextControl.ASP.SDK, fails when it processes documents on App Service on Windows. The Windows sandbox of App Service blocks the graphics and user interface functions that the Classic engine uses; move the application to the Core engine, as Before You Create the App Service describes.
Only a Few Editors Connect
The first editors work, but further users can't connect; on Linux, further connections are rejected with the status code 429.
App Service limits the WebSocket connections per instance, and each editor opens two of them while it initializes: five in the Free tier on Linux, and 350 in the Basic tier on Windows. Choose the Basic tier or higher on Linux, and the Standard tier or higher on Windows for more connections. The deployment pages Azure App Service on Windows and Azure App Service on Linux list the limits.
Editors Lose Their Sessions When the App Service Scales Out
With several instances, editors lose their session after a short connection loss, and reconnectionFailed reports Could not reconnect. Connection ID is unknown to the synchronization service. The reconnecting editor reached another instance. Keep Session affinity on in the General settings of the App Service, which is the default; Reconnecting Fails Behind a Load Balancer explains the cause.
Fonts Differ on Linux
Documents created on App Service on Linux use other fonts than on the development machine, because the Core engine takes its fonts only from the Fonts folder published with the application. See Text Appears in Another Font.
The Packages Don't Restore in Azure DevOps
The build pipeline in Azure DevOps can't restore the TX Text Control packages from the Text Control Private NuGet Feed. See The Restore Fails on a Build Server.