Table of Contents

Usage in Docker and Azure App Service

This page covers how to run List & Label Cross Platform within a Docker container and deploy your containerized application to Azure App Service.

Running in Docker

List & Label Cross Platform is designed for containerized deployments. Docker containers provide consistent, reproducible environments across development, testing, and production.

LLCP supports .NET 10 and .NET 11. The examples below use .NET 10 as the default. To use .NET 11, keep the structure and only adjust the image tags (as described in the notes below).

Why Docker for LLCP?

Dependency isolation
All required native libraries (font handling, image rendering) are packaged within the container, avoiding conflicts with host system packages.

Cross-platform consistency
The same container image runs identically on Windows, Linux, and macOS (via Docker Desktop), eliminating platform-specific differences.

Scalability
Containers can be replicated and orchestrated (Kubernetes, ECS, Azure Container Instances) to handle variable workloads.

Simplified deployment
A single container image includes application code, runtime dependencies, and native libraries, reducing deployment complexity.

Required dependencies

Important

List & Label Cross Platform requires additional native Linux packages for font handling and image rendering. These must be installed explicitly in your Docker image.

When running on Linux, you must also reference the NuGet package combit.ListLabel32.CrossPlatform.NativeAssets.Linux, which provides the required native rendering components and the enhanced PDF engine.

Dockerfile variants (overview)

Choose the Dockerfile variant that best fits your environment:

Variant Base image Package manager Recommended when
Debian / Ubuntu mcr.microsoft.com/dotnet/aspnet:10.0 apt-get maximum compatibility, easiest troubleshooting
Alpine mcr.microsoft.com/dotnet/aspnet:10.0-alpine apk smaller image size
Note

List & Label Cross Platform supports .NET 10 and .NET 11. Only the image tags need to be changed for different .NET versions. Package names may differ slightly depending on the Linux distribution.

Use this variant when your runtime image is based on Debian or Ubuntu (e.g. mcr.microsoft.com/dotnet/aspnet:10.0).

# Build and publish the application
FROM mcr.microsoft.com/dotnet/sdk:10.0 AS build
WORKDIR /src
COPY . .
RUN dotnet publish -c Release -o /app/publish

# Runtime image
FROM mcr.microsoft.com/dotnet/aspnet:10.0
WORKDIR /app
COPY --from=build /app/publish ./

USER root

# Install native dependencies required by List & Label Cross Platform
RUN apt-get update && apt-get install -y \
    libc6 \
    libfontconfig1 \
    libfreetype6 \
    libpng16-16 \
    libjpeg62 \
    libgif7 \
    fonts-dejavu-core \
 && apt-get clean && rm -rf /var/lib/apt/lists/*

ENTRYPOINT ["dotnet", "YourApplication.dll"]
Note

Depending on the Debian/Ubuntu version behind the base image, the JPEG package may be named libjpeg62 or libjpeg62-turbo. If installation fails, check the available package names and adjust accordingly.

Tip

To use a different .NET version:

  • .NET 11
    mcr.microsoft.com/dotnet/sdk:11.0
    mcr.microsoft.com/dotnet/aspnet:11.0

Deploying to Azure App Service

Azure App Service supports running Docker containers directly, so an LLCP-based application can be deployed as a container image without additional orchestration.

Steps to deploy

  1. Build your Docker image:
    Build your Docker image locally or in your CI/CD pipeline using your Dockerfile. For example:

    docker build -t mylistlabelapp .

  2. Push the image to a container registry:
    Push the image to a container registry like Azure Container Registry (ACR) or Docker Hub:

    docker tag mylistlabelapp myregistry.azurecr.io/mylistlabelapp:latest
docker push myregistry.azurecr.io/mylistlabelapp:latest

  3. Create an Azure App Service instance:
    In the Azure Portal, create a new App Service configured for Docker. Choose the "Container" option, and provide the image source details (e.g., registry URL, image name, and tag).

  4. Configure deployment settings:

    • Container settings:
      Configure startup commands if necessary, and ensure that environment variables (licensing, connection strings) are properly set using App Service configuration.
    • Continuous deployment (optional):
      Set up continuous deployment from your container registry for automated updates when new images are pushed.
    • Scaling:
      Configure scale-out rules based on CPU, memory, or custom metrics (e.g., queue depth).

  5. Configure monitoring:

    • Enable Application Insights for request tracing, performance metrics, and error tracking
    • Set up alerts for failures, high latency, or resource exhaustion
    • Use log streaming to troubleshoot issues during deployment

  6. Security best practices:

    • Store secrets (licensing info, connection strings) in Azure Key Vault
    • Use managed identities for authentication to Azure resources
    • Enable HTTPS and consider custom domains with SSL certificates

Production considerations

Resource sizing
Start with the Basic or Standard tier and scale based on load. Use App Service metrics to determine optimal instance size and count.

Deployment slots
Use staging slots to test changes before swapping to production, enabling zero-downtime deployments.

LLCP itself has no App Service-specific requirements beyond the container contents covered above. For the underlying design rules that drive sizing and scaling decisions — ListLabel not being thread-safe, per-render memory usage, statelessness — see Summary of key design rules; the same rules apply outside Kubernetes.

For Azure-specific configuration (health checks, monitoring, secrets, networking), see the official Azure App Service documentation.