This guide explains how to build and run a Docker container for a published ASP.NET application using Winnovative PDF Next on Windows.
Winnovative PDF Next can run in Windows Docker containers based on Windows Server images such as Windows Server LTSC 2022 with the mcr.microsoft.com/windows/server:ltsc2022 image reference and Windows Server LTSC 2025 with the mcr.microsoft.com/windows/server:ltsc2025 image reference.
These images do not include the ASP.NET Core Runtime, which will be installed in the Dockerfile. In the Dockerfile examples below the ASP.NET Core 8.0 Runtime is installed on Windows Server LTSC 2022 and the ASP.NET Core 10.0 Runtime is installed on Windows Server LTSC 2025.
It can also run on Windows Server Core with Pre-Installed ASP.NET Core Runtime images such as Windows Server Core LTSC 2022 with ASP.NET Core Runtime 8.0 having the mcr.microsoft.com/dotnet/aspnet:8.0-windowsservercore-ltsc2022 image reference and Windows Server Core LTSC 2025 with ASP.NET Core Runtime 10.0 having the mcr.microsoft.com/dotnet/aspnet:10.0-windowsservercore-ltsc2025 image reference.
Windows Server Core images don't have fonts installed by default, so you need to copy the fonts from a Windows host into the container and register them. This is automatically done in the Dockerfile examples.
Download the Winnovative PDF Next ZIP package from the website downloads page and extract it to a folder on your machine. In the Windows folder of the extracted package you can find the demo application which references the Winnovative PDF Next library NuGet package for Windows. You can open the Winnovative_Next_AspNetDemo_Windows.csproj file in Visual Studio and publish it to a folder or you can publish it from the command line.
To publish from the command line run the following command in the application folder containing the Winnovative_Next_AspNetDemo_Windows.csproj project file:
dotnet publish -c Release -r win-x64 -o publish Winnovative_Next_AspNetDemo_Windows.csprojYou can find more details about building and publishing the Winnovative PDF Next demo applications in the Build and Publish Demo Applications guide from the documentation.
This publish folder should include the main DLL (for example Winnovative_Next_AspNetDemo_Windows.dll) and the winnovative_runtimes directory at the root level.
Place this publish folder in the build context folder of the Windows host file system, which will also contain the Dockerfile.
Winnovative PDF Next can run in Windows Server containers with ASP.NET Core Runtime.
Below you can find the Dockerfile configuration for Windows Server LTSC 2022 and Windows Server LTSC 2025. Copy the contents into a file named Dockerfile and place it in the build context folder together with the publish and Fonts folders.
The Dockerfile downloads and installs the ASP.NET Core Runtime from a ZIP archive, copies the published application into the image and configures the container to run the demo application on port 27102.
On Windows Server LTSC 2022 the ASP.NET Core 8.0 Runtime is installed and on Windows Server LTSC 2025 the ASP.NET Core 10.0 Runtime is installed. It is also possible to install other versions of the ASP.NET Core Runtime by changing the download URL in the Dockerfile and the target framework when publishing the application. Make sure to use compatible versions of the ASP.NET Core Runtime and the target framework of the application.
FROM mcr.microsoft.com/windows/server:ltsc2022
# Use PowerShell as default shell
SHELL ["powershell", "-Command"]
# Install .NET 8.0 ASP.NET Core Runtime from ZIP
RUN Invoke-WebRequest -Uri 'https://builds.dotnet.microsoft.com/dotnet/aspnetcore/Runtime/8.0.22/aspnetcore-runtime-8.0.22-win-x64.zip' -OutFile 'C:\\dotnet.zip'; \
Expand-Archive -Path 'C:\\dotnet.zip' -DestinationPath 'C:\\dotnet'; \
Remove-Item 'C:\\dotnet.zip' -Force
ENV DOTNET_ROOT=C:\dotnet
WORKDIR C:/app
# Copy the published ASP.NET Core app files from the publish folder into the image
COPY publish/ .
EXPOSE 27102
ENV ASPNETCORE_URLS=http://+:27102
ENTRYPOINT ["C:\\dotnet\\dotnet.exe", "C:\\app\\Winnovative_Next_AspNetDemo_Windows.dll"]FROM mcr.microsoft.com/windows/server:ltsc2025
# Use PowerShell as default shell
SHELL ["powershell", "-Command"]
# Install .NET 10.0 ASP.NET Core Runtime from ZIP
RUN Invoke-WebRequest -Uri 'https://builds.dotnet.microsoft.com/dotnet/aspnetcore/Runtime/10.0.0/aspnetcore-runtime-10.0.0-win-x64.zip' -OutFile 'C:\\dotnet.zip'; \
Expand-Archive -Path 'C:\\dotnet.zip' -DestinationPath 'C:\\dotnet'; \
Remove-Item 'C:\\dotnet.zip' -Force
ENV DOTNET_ROOT=C:\dotnet
WORKDIR C:/app
# Copy the published ASP.NET Core app files from the publish folder into the image
COPY publish/ .
EXPOSE 27102
ENV ASPNETCORE_URLS=http://+:27102
ENTRYPOINT ["C:\\dotnet\\dotnet.exe", "C:\\app\\Winnovative_Next_AspNetDemo_Windows.dll"]Winnovative PDF Next can run in Windows Server Core containers with pre-installed ASP.NET Core Runtime.
Windows Server Core images don't have fonts installed by default, so you need to copy the fonts from a Windows host into the container and register them. This is done in two steps. First copy the fonts from your host machine into the local build context folder then copy and register them into the Docker image in the Dockerfile.
You can simply copy the Fonts folder from your Windows host machine into the build context folder using either the command line or Windows Explorer. The Fonts folder is usually located at C:\Windows\Fonts on your host machine. You can also use the PowerShell script below to perform this automatically.
$sourceFontsPath = Join-Path $env:SystemRoot "Fonts"
$targetFontsPath = ".\Fonts"
if (-not (Test-Path $targetFontsPath)) {
New-Item -ItemType Directory -Path $targetFontsPath | Out-Null
}
Copy-Item -Path (Join-Path $sourceFontsPath "*") -Destination $targetFontsPath -ForceCopy the PowerShell script into a file named Prepare-Fonts.ps1 in the build context folder open PowerShell navigate to the folder and run it using the .\Prepare-Fonts.ps1 command. It will create a Fonts folder in the build context containing the required fonts.
Below you can find the Dockerfile configuration for Windows Server Core LTSC 2022 with ASP.NET Core Runtime 8.0 and for Windows Server Core LTSC 2025 with ASP.NET Core Runtime 10.0. Copy the contents into a file named Dockerfile and place it in the build context folder together with the publish and Fonts folders.
The Dockerfile copies the fonts and the published application into the image and configures the container to run the demo application on port 27102.
FROM mcr.microsoft.com/dotnet/aspnet:8.0-windowsservercore-ltsc2022
SHELL ["powershell", "-Command"]
# Copy fonts from build context into the image Fonts folder
COPY Fonts/ C:/Windows/Fonts/
# Register fonts in container's Windows registry
RUN $ErrorActionPreference = 'Stop'; \
Get-ChildItem 'C:\Windows\Fonts' -Include *.ttf, *.ttc -Recurse | ForEach-Object { \
$file = $_.Name; \
$name = [System.IO.Path]::GetFileNameWithoutExtension($file); \
$regName = $name + ' (TrueType)'; \
New-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts' -Name $regName -PropertyType String -Value $file -Force | Out-Null \
}
# Set working directory for the app
WORKDIR C:/app
# Copy the published ASP.NET Core app files from the publish folder into the image
COPY publish/ .
# Expose the application port
EXPOSE 27102
# Configure ASP.NET Core to listen on all interfaces and port 27102
ENV ASPNETCORE_URLS=http://+:27102
# Run the application
ENTRYPOINT ["dotnet", "C:\\app\\Winnovative_Next_AspNetDemo_Windows.dll"]This Dockerfile is similar to the previous one but uses the Windows Server Core LTSC 2025 image with ASP.NET Core Runtime 10.0. A small delay is added before starting the application because Windows Server Core 2025 containers start some critical Windows services (such as RPC and Event Log) asynchronously on first launch and .NET 10 initializes Windows Event Log very early during its startup sequence. This can cause a brief startup race condition unless a short delay is added. The delay ensures these services are fully ready and does not affect application performance after startup.
To completely avoid this delay you can disable the Windows Event Log logging provider by setting the environment variable Logging__EventLog__LogLevel__Default to None before the ENTRYPOINT. This is a recommended best practice when running .NET applications inside Windows containers.
FROM mcr.microsoft.com/dotnet/aspnet:10.0-windowsservercore-ltsc2025
SHELL ["powershell", "-Command"]
# Copy fonts from build context into the image Fonts folder
COPY Fonts/ C:/Windows/Fonts/
# Register fonts in container's Windows registry
RUN $ErrorActionPreference = 'Stop'; \
Get-ChildItem 'C:\Windows\Fonts' -Include *.ttf, *.ttc -Recurse | ForEach-Object { \
$file = $_.Name; \
$name = [System.IO.Path]::GetFileNameWithoutExtension($file); \
$regName = $name + ' (TrueType)'; \
New-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts' -Name $regName -PropertyType String -Value $file -Force | Out-Null \
}
# Set working directory for the app
WORKDIR C:/app
# Copy the published ASP.NET Core app files from the publish folder into the image
COPY publish/ .
# Expose the application port
EXPOSE 27102
# Configure ASP.NET Core to listen on all interfaces and port 27102
ENV ASPNETCORE_URLS=http://+:27102
# Run the application
ENTRYPOINT ["powershell", "-Command", "Start-Sleep -Seconds 3; dotnet C:\\app\\Winnovative_Next_AspNetDemo_Windows.dll"]Once the Dockerfile is created as described in the previous sections you can build and run the container using the following commands.
Open PowerShell or Command Prompt with Docker configured for Windows containers and build the image using:
docker build -t winnovative-pdf-next-demo-image-windows .After the image is built run the container and map port 27102 from the container to your host machine:
docker run -d -p 27102:27102 --name winnovative-pdf-next-demo-app-windows winnovative-pdf-next-demo-image-windowsOnce the container is running open your browser and navigate to:
http://localhost:27102You can also publish the Docker image to Azure Container Registry (ACR) and run the application from there enabling easier deployment and integration within Azure-based environments.