Deployment Guide
An application built with TX Text Control .NET Server takes TX Text Control with it: publishing puts the engine, its native libraries, its fonts and the Document Editor backend next to your application, and the license is compiled into your assembly. No setup runs on the target. What differs from one target to the next is how the application is hosted, how the Document Editor's connection gets through and what the platform expects from the runtime.
What Every Deployment Has in Common
- An engine for the target platform. The Core engine in
TXTextControl.TextControl.Core.SDKruns on Windows and Linux; the Classic engine runs on Windows only. Publish for the runtime identifier of the target,win-x64orlinux-x64. - A publish output with everything TX Text Control needs. Next to your application,
dotnet publishputs the TX Text Control assemblies, the native libraries of the target platform, the Fonts folder of the Core engine and the files of the Document Editor backend. - The .NET runtime on the target. Text Control's examples publish framework-dependent applications. The Document Editor backend runs as a separate
dotnetprocess with the installed runtime and listens on TCP port 4283, which only your application uses. - A path for the WebSocket connection. Every server, proxy and load balancer between the browser and your application must let the Document Editor's WebSocket connection through, and with several instances, keep it on one instance. WebSocket Architecture explains the connection.
- Runtime licenses. Each production server, virtual machine or cloud instance needs one. See Runtime Licenses.
Choose a Target
| Target | Read |
|---|---|
| Windows Server with IIS, or a Windows service | Windows |
| Ubuntu or Debian with systemd and nginx | Linux |
| Linux containers, fonts in the image, several containers | Docker |
| Kubernetes clusters, with Deployments, Services and session affinity | Kubernetes |
| Azure App Service on Windows or Linux | Azure |
| AWS Elastic Beanstalk or AWS Fargate | AWS |
| Google Cloud Run | Google Cloud |
| Build, publish and deploy in a pipeline | CI/CD |
Find the Right Page
| If you want to | Read |
|---|---|
| Check what a Linux server or container needs: glibc, gconv, ports, processes | Linux Requirements |
| Configure an IIS application pool so that the Document Editor backend keeps running | IIS |
| Build a container image without putting the NuGet feed credentials into it | Dockerfile |
| Add company fonts to a deployment | Fonts |
| Run the Document Editor backend separately from the application | Multiple Processes |
| Find out which requests need sticky sessions behind a load balancer | Scaling Containers |
Where to Start
- Operating Systems: confirm that the target platform and the engine fit.
- The section of your target: Windows, Linux, Docker or Azure.
- CI/CD: automate the deployment.
- Troubleshooting: when the application or the editor doesn't start on the target.