In a container, TX Text Control .NET Server depends on what the image contains, on how docker build reaches the private NuGet feed and on how the Document Editor backend is placed: in the application's container or in one of its own. Dockerfile in the Deployment Guide builds an image that avoids them; the Linux libraries behind some of them are explained on Linux.

Read the Output of the Container

Run the container in the foreground and read its output:

docker run --rm -p 8080:8080 myapp

A working container logs Started TXTextControl.Web.Server.Core and Starting TCP listener on port 4283 before the application listens on port 8080, and each editor that connects adds the line Starting web editor worker process with connection ID. Lines with the prefix [TXTextControl.Web.Server.Core] come from the backend. Build and Run the Image shows the complete output.

The Container Stops When It Creates a PDF

The application process ends without an error message as soon as it creates a PDF document, or the container doesn't work at all with the chosen base image.

Not every ASP.NET Core image contains what TX Text Control needs: chiseled images leave out the gconv modules, the plain chiseled image also lacks ICU, and Alpine doesn't work at all.

Use mcr.microsoft.com/dotnet/aspnet:10.0, or 8.0 for a .NET 8 application. Choose the Base Image compares the images.
For a chiseled image, use the -extra variant and copy the gconv modules from the regular image, as Use a Chiseled Image shows.

Fonts Are Missing in the Container

Documents created in the container use other fonts than on the development machine, although font packages were installed in the Dockerfile.

The Core engine doesn't use fonts installed in the image; it reads the Fonts folder published with the application. Add the fonts to that folder instead, as A Font Installed on the Server Isn't Used describes. In Windows containers with the Classic engine, the fonts installed in the container are used instead.

docker build Can't Restore the Packages

The restore in docker build fails for the TX Text Control packages, or the publish after it ends with error NETSDK1047.

The build stage restores from the Text Control Private NuGet Feed, which needs the credentials in your nuget.config. A Dockerfile generated by Visual Studio restores without them. Pass nuget.config to the restore as a build secret, restore with -r linux-x64 when the publish runs with --no-restore, and keep the file out of the image with .dockerignore. Write the Dockerfile shows the complete file and the build command. If the feed rejects the credentials, see NuGet Authentication.

The Site Isn't Reachable

The container runs, but the browser can't reach the application.

ASP.NET Core in the .NET images listens on port 8080. The port of the Document Editor backend, 4283, is used only inside the container.

Map port 8080 of the container: docker run --rm -p 8080:8080 myapp.
Don't publish port 4283. Articles for version 33.0 map port 4282; don't copy their port numbers.

The Backend Doesn't Start in the Container

The output shows Error starting TXTextControl.Web.Server.Core: An error occurred trying to start process 'dotnet', and the application ends.

Start the application with ENTRYPOINT ["dotnet", "MyApp.dll"], and publish with /p:UseAppHost=false and without --self-contained. The Backend Can't Start the dotnet Command explains the cause.

The Editor Can't Reach a Backend in Another Container

The Document Editor backend runs in a container of its own, and the application container doesn't start, with a SocketException from the constructor of TXTextControl.Web.WebSocketMiddleware in its log, or the editor doesn't connect.

The application resolves the host name of the backend container once, at startup, and a backend that listens only on the loopback address isn't reachable from another container. Start the backend with --listen-address 0.0.0.0, let the application depend on it with depends_on, and restart the application container after the backend container was recreated. Run the Backend in Its Own Container shows both projects and the Compose file.

Several dotnet Processes Run in the Container

The process list of the container shows several dotnet processes.

This is expected: besides the application, the container runs the backend and one worker process for each connected editor. The Processes of an Application describes them, including what happens when the backend ends. A liveness probe on the application doesn't notice a backend that has ended; watch the log for the backend's messages.

Docker