TX Text Control .NET Server

Azure App Service Linux

Topic

On Linux, Azure App Service needs fewer preparations for TX Text Control .NET Server than on Windows. WebSockets are always available, there's no 32-bit platform to switch off and the Core engine brings its fonts with the application. The application only has to be published for linux-x64, so that the native Linux libraries of TX Text Control are part of the deployment.

The steps follow Text Control's tutorial and publish the application of Document Editor: ASP.NET Core from Visual Studio or with the Azure CLI. A last section shows the settings for a container image instead of code.

Prerequisites

  • An Azure subscription.
  • An ASP.NET Core application with the Core engine, for example the application of Document Editor: ASP.NET Core. The Classic engine doesn't run on Linux.
  • Visual Studio 2026, or the .NET CLI and the Azure CLI.
  • A plan in the Basic tier or higher. In the Free tier, a Linux app accepts five WebSocket connections, and further connections are rejected with status 429. An editor opens two WebSocket connections while it initializes.
  • Runtime licenses. Each instance of the App Service needs one. See Runtime Licenses.

Create the App Service and Publish From Visual Studio

  1. In Solution Explorer, right-click the project and choose Publish.

  2. Select Azure as the target and click Next.

  3. Select Azure App Service (Linux) and click Next.

    The Publish dialog asking which Azure service hosts the application, with Azure App Service (Linux) selected among Azure Container Apps (Linux), Azure App Service (Windows), Azure App Service Container, Azure Container Registry and Azure Virtual Machine.

  4. Sign in to your Azure account. Select an existing App Service, or click Create new.

  5. For a new App Service, enter the Name, select the Subscription name, the Resource group and a Hosting Plan in the Basic tier or higher and click Create.

    The App Service (Linux) Create new dialog of Visual Studio with the fields Name, Subscription name, Resource group and Hosting Plan.

  6. Check the summary and click Finish. Visual Studio creates a publish profile.

  7. In the settings of the publish profile, keep Configuration at Release and Deployment Mode at Framework-dependent, and make sure that Target Runtime is linux-x64. Click Publish.

    The Zip Deploy publish profile for Azure App Service (Linux) with Configuration Release, Deployment Mode Framework-dependent and Target Runtime linux-x64 circled, and the Publish button circled.

Visual Studio publishes the application and opens it in the browser. The page with the Document Editor shows the editor with its ribbon. Unlike on Windows, no setting in the Azure portal is needed first.

The Document Editor with its ribbon, a welcome text and a table, running in a browser at an azurewebsites.net address.

Publish With the Azure CLI

Without Visual Studio, create a Linux plan in the Basic tier and the web app:

az appservice plan create -g MyResourceGroup -n MyPlan --is-linux --sku B1
az webapp list-runtimes --os-type linux
az webapp create -g MyResourceGroup -p MyPlan -n <app-name> --runtime <runtime>

Use a .NET value from the output of az webapp list-runtimes for --runtime. Publish the application for linux-x64, pack the output into a ZIP file and deploy it:

dotnet publish -c Release -r linux-x64 --self-contained false -o publish
Compress-Archive -Path publish\* -DestinationPath app.zip
az webapp deploy -g MyResourceGroup -n <app-name> --src-path app.zip

A ZIP deployment doesn't build the application on App Service, so the packages from the Text Control Private NuGet Feed are restored only on your machine or build server.

Configure the Application With App Settings

App settings in the App Service override the values of appsettings.json. On Linux, nested keys use two underscores instead of the colon. To bind the Document Editor backend to the loopback address, for example, with DocumentEditorWorkerOptions bound as in Prepare the Application:

az webapp config appsettings set -g MyResourceGroup -n <app-name> --settings DocumentEditorWorker__ListenAddress=127.0.0.1 DocumentEditorWorker__Port=4283

Pass the same address and port to UseTXWebSocketMiddleware in Program.cs.

Check the Application

  • Open the site at its default domain, which has the form <app-name>-<hash>.<region>.azurewebsites.net.

  • Turn on and stream the logs of the container that runs your application:

    az webapp log config -g MyResourceGroup -n <app-name> --docker-container-logging filesystem --level Verbose
az webapp log tail -g MyResourceGroup -n <app-name>

    The application passes the messages of the Document Editor backend to its logging, so lines such as "Starting TCP listener on port 4283" appear here. A 404 for /robots933456.txt is a health check of App Service and can be ignored.

  • Open a shell in the container with az webapp ssh -g MyResourceGroup -n <app-name>. Changes outside /home are lost when the app restarts.

Deploy a Container Image

App Service on Linux also runs a container image, for example the image from Dockerfile pushed to Azure Container Registry. In the Azure portal, select App Services > Create > Web App, choose Container and Linux on the Basics tab and select the registry, the image and the tag on the Container tab.

The .NET images listen on port 8080. Tell App Service the port of the container:

az webapp config appsettings set -g MyResourceGroup -n <app-name> --settings WEBSITES_PORT=8080

App Service can expose only one HTTP port of a container. The Document Editor backend runs inside the same container and needs no exposed port.

Run Several Instances

When the App Service scales out, keep Session affinity on, which is the default, and plan a runtime license for each instance, as Scaling and Licensing describes.

Next Steps