TX Text Control .NET Server

CI/CD

Topic

A pipeline for an application with TX Text Control .NET Server is an ordinary .NET pipeline with three additions: the credentials for the Text Control Private NuGet Feed, a publish step for the runtime the application runs on and, for containers, an image build that keeps the credentials out of the image. Everything else, from tests to deployment slots, works as in any other .NET project.

The restore from the private feed is described step by step in CI/CD Authentication, for GitHub Actions, GitLab, Azure DevOps, Jenkins, Bitbucket and TeamCity. The sections below continue where those pipelines end: with publishing, artifacts and deployment.

What Build Servers Need

  • The feed credentials as secrets. The pipeline writes nuget.config from the secrets before the first dotnet command, as CI/CD Authentication shows. Write the file to the root of the repository, above the project folders.
  • No license for the build server. TX Text Control is licensed per developer, not per build server. See Build Servers and CI/CD.
  • An x64 agent on Windows or Linux for tests that use ServerTextControl. The Core package contains native libraries for win-x64 and linux-x64 only, so such tests don't run on macOS or ARM64 agents. On Linux, the agent must meet the Linux Requirements.

Publish for the Target Runtime

Publish the application for the runtime identifier of the servers it runs on:

dotnet publish MyApp/MyApp.csproj -c Release -r linux-x64 --self-contained false -o publish

Use -r win-x64 for Windows servers and Azure App Service on Windows. The command works as follows:

  • -r linux-x64 puts the native libraries of that platform next to the application, together with the Fonts folder of the Core engine and the files of the Document Editor backend. Without a runtime identifier, the output contains the native libraries of all platforms in a runtimes folder.
  • --self-contained false leaves out the .NET runtime, which the servers or App Service provide. Text Control's publishing examples use framework-dependent deployments. The Document Editor backend runs as a separate process with the installed .NET runtime in any case.
  • dotnet publish restores the packages again for the runtime identifier. Keep nuget.config in place until the publish step has run, or restore with -r linux-x64 beforehand and publish with --no-restore.

Don't write nuget.config into the project folder. A web project copies .config files from its folder into the publish output, and an artifact or a deployed package would then contain the API token of the feed. In the root of the repository, dotnet restore still finds the file.

Upload the Output as an Artifact

In GitHub Actions, add a publish step and an upload step after the test step of the workflow from CI/CD Authentication:

      - name: Publish
        run: dotnet publish MyApp/MyApp.csproj -c Release -r linux-x64 --self-contained false -o publish

      - name: Upload artifact
        uses: actions/upload-artifact@v4
        with:
          name: myapp
          path: publish

A later job or workflow deploys the artifact. For Azure App Service, Microsoft describes the sign-in and deployment steps in Deploy to App Service using GitHub Actions.

Deploy to Azure App Service With Azure Pipelines

In Azure Pipelines, the .NET Core task publishes the web project into a ZIP file, and the Azure Web App task deploys it. Add both tasks after the restore of the pipeline from CI/CD Authentication:

  - task: DotNetCoreCLI@2
    displayName: 'Publish'
    inputs:
      command: 'publish'
      publishWebProjects: true
      arguments: '--configuration Release -r linux-x64 --self-contained false'
      zipAfterPublish: true

  - task: AzureWebApp@1
    displayName: 'Deploy'
    inputs:
      azureSubscription: '<service-connection-name>'
      appType: 'webAppLinux'
      appName: '<app-name>'
      package: '$(System.DefaultWorkingDirectory)/**/*.zip'

The tasks work as follows:

  • arguments passes the runtime identifier to dotnet publish. For App Service on Windows, use -r win-x64 and set appType to webApp.
  • azureSubscription is the name of an authorized service connection to your Azure subscription.
  • package finds the ZIP file that the publish task created.

App Service on Windows needs the 64-bit platform and Web sockets before the first deployment. Azure App Service Windows describes these settings, and Microsoft's article Configure CI/CD with Azure Pipelines covers deployment slots and approvals.

Build a Container Image in the Pipeline

For containers, the pipeline builds the image with the Dockerfile from Dockerfile and passes the generated nuget.config as a build secret:

docker buildx build --secret id=nugetconfig,src=nuget.config -t myregistry.example.com/myapp:1.0.0 .
docker push myregistry.example.com/myapp:1.0.0

The Dockerfile restores and publishes inside the build, so the pipeline needs no dotnet steps of its own for the image. The secret is available only during the restore and isn't part of any image layer. Sign in to your registry before docker push, as your registry requires.

Check Templates Before Deployment

Templates that reach a server can depend on fonts, images and data fields that exist only on a developer machine. The sample project TXTextControl.Check.Dependencies loads a template with ServerTextControl and reports missing fonts, linked images that don't exist and fields or blocks of the JSON data that the template doesn't contain as merge fields, merge blocks or form fields. The blog article Check TX Text Control Template Dependencies Before Deployment suggests running such a check in a pipeline with the same package version and Fonts folder as production. The sample prints its results and doesn't set an exit code, so add one if the check should stop a pipeline.

Keep the Versions Consistent

  • NuGet packages. Reference TXTextControl.TextControl.Core.SDK, TXTextControl.Web and TXTextControl.Web.DocumentEditor.Backend explicitly: the backend and web packages don't declare a dependency on the Core package. Pin the versions, so that every build restores the same packages; see Package Versioning.
  • npm packages. Angular and React frontends use npm packages whose major version must match the major version of TX Text Control .NET Server on the backend. Update both together, as Updating npm Packages describes.

Next Steps