# Check TX Text Control Template Dependencies Before Deployment > When templates are moved from Windows to Linux, from TX Text Control Classic to Core, or from one server to another, missing fonts, images, merge fields, blocks, and form field names can break output. This article shows how a small dependency checker validates templates before deployment. - **Author:** Bjoern Meyer - **Published:** 2026-07-28 - **Modified:** 2026-07-28 - **Description:** When templates are moved from Windows to Linux, from TX Text Control Classic to Core, or from one server to another, missing fonts, images, merge fields, blocks, and form field names can break output. This article shows how a small dependency checker validates templates before deployment. - **8 min read** (1466 words) - **Tags:** - .NET - C# - Templates - Validation - Linux - ServerTextControl - **Web URL:** https://www.textcontrol.com/blog/2026/07/28/check-tx-text-control-template-dependencies-before-deployment/ - **LLMs URL:** https://www.textcontrol.com/blog/2026/07/28/check-tx-text-control-template-dependencies-before-deployment/llms.txt - **LLMs-Full URL:** https://www.textcontrol.com/blog/2026/07/28/check-tx-text-control-template-dependencies-before-deployment/llms-full.txt - **GitHub Repository:** https://github.com/TextControl/TXTextControl.Check.Dependencies --- Templates are often created in one environment and processed in another. For example, a contract template might be designed on a Windows workstation and tested with TX Text Control Classic. Later, it could be processed by a Linux container using TX Text Control Core. Another template may be copied from an existing customer installation to a new application server. In both cases, only the document file itself is part of the deployment. The template depends on its runtime environment and the data contract used to merge or prefill it. Fonts must be available. Referenced images must exist on the server. Additionally, merge fields, merge blocks, and form field names must match the JSON data source used by the application. > **Template Dependency Checks** > > Before deploying templates to another server or moving from Windows to Linux, validate fonts, linked images, merge fields, merge blocks, and form field names against the target runtime and data source. ### Why Template Dependencies Matter Issues with templates are often discovered too late. For example, a document may load successfully during development but look different when generated as a PDF on the production server because a font has been substituted. Similarly, a referenced image may exist on the authoring machine but not on the server. A merge data object might contain customer.firstName, while the document still expects customer.name. These problems are especially noticeable when applications transition from Windows to Linux. TX Text Control Classic applications usually run on Windows systems, which typically have fonts such as Arial, Calibri, and Times New Roman installed. However, TX Text Control Core applications often run in Linux containers or server environments, where a different set of fonts is available. If a template contains a font that is unavailable, TX Text Control adapts the font during loading and rendering. ### Classic to Core: The Font Difference When porting from TX Text Control Classic to TX Text Control Core, document logic may stay the same, but the available font environment changes. Windows desktop and server installations frequently include fonts that are not present in Linux containers. If a template was designed with Arial and the target Linux environment only contains Liberation Sans, the output can still be produced, but text metrics and page breaks can change. The dependency checker uses ServerTextControl and enables FontSettings.AdaptFontEvent before loading the template. The AdaptFont event reports fonts that are not available in the current runtime environment. The checker stores the missing font names so they can be reviewed before the template is released. ### Moving Templates Between Servers The same idea applies when templates are transferred between systems. A template may contain images that are inserted as references. In this case, the document stores a file path, so the file must be available when the template is loaded or rendered. However, if the path points to a user desktop, network share, or old application folder, the new server will not be able to resolve it. The checker walks through all text parts and verifies image references: ``` foreach (TXTextControl.Image image in formattedText.Images) { if (image.FileName != null && !File.Exists(image.FileName)) { // Add the missing image path to the info object. } } ``` This makes it easy to distinguish embedded images from linked images and to catch server-specific paths before deployment. ### Checking the Data Contract Many templates are not only documents; they are contracts between the template designer and the application that provides data. The checker can compare the template against a JSON data source and list data fields that are not represented in the document. For example, this JSON data source contains a nested customer object and a repeating collection: ``` { "customer": { "name": "Text Control", "firstName": "Text" }, "lineItems": [] } ``` The checker reports missing document elements for fields or blocks that exist in the data but are not used by the template. This is useful when a template is expected to consume a defined JSON payload. It helps answer practical questions such as: Does the document contain a merge block for lineItems? Is customer.firstName used? Are the form field names still aligned with the data source? ### Dot Notation and Merge Blocks TX Text Control templates can use dot notation such as customer.name. But the same data can also be represented by a merge block named customer and an inner merge field named name. Both patterns are valid, and a checker should treat them as equivalent when validating a JSON contract against a template. The tool handles this by checking for exact dotted merge field names and by allowing dotted JSON fields to be satisfied by a matching merge block and inner field. A JSON field named customer.name is considered present if the document contains either customer.name or a customer block with a name field. ### Using the Checker The API is intentionally small. Load the template and optionally pass JSON data: ``` using TXTextControl.DocumentServer.Validation; var checker = new TemplateDependencyChecker(); TemplateDependencyInfo info = checker.Check( "contract.tx", TXTextControl.StreamType.InternalUnicodeFormat, jsonData); ``` The returned TemplateDependencyInfo object contains separate collections for missing fonts, missing images, and data fields or blocks that are not represented in the document. ``` foreach (MissingFontDependency font in info.MissingFonts) { Console.WriteLine($"Missing font: {font.FontName}"); } foreach (MissingImageDependency image in info.MissingImages) { Console.WriteLine($"Missing image: {image.FileName}"); } foreach (MissingDocumentFieldDependency field in info.DataDependencies.MissingDocumentFields) { Console.WriteLine($"Merge field missing in document: {field.Name}"); } ``` ### Typical Output A dependency check can produce output like this: ``` Template: test.tx Missing dependencies found: True Missing font: Arial Missing image: C:\Users\BjoernMeyer\Desktop\test.png Missing image: C:\Users\BjoernMeyer\Desktop\thumbnail.jpg Merge block missing in document: lineItems ``` In this example, the template uses Arial, but Arial is not available in the current runtime. It also references two image files that do not exist on the server. The JSON data source contains a lineItems array, but the document does not contain a matching merge block. ### When to Use It It is most useful to run a template dependency check before a template crosses an environment boundary. Run the check when moving templates from a development workstation to a test or production server, migrating from TX Text Control Classic to TX Text Control Core, deploying to Linux containers, or importing templates from an existing customer installation. It is also useful in CI pipelines. A build step can load each template with the same runtime package and font folder used in production, then compare it to the expected JSON schema or sample data. This allows the template author to fix problems before users generate documents. ### Conclusion Template validation should happen before the first production merge. Missing fonts, missing image references, and mismatched data fields are deployment problems, not document-generation surprises. A small checker based on ServerTextControl can load the actual template in the target runtime and return a structured dependency report. This is especially valuable when moving from Windows to Linux or from TX Text Control Classic to Core, because the document engine, font environment, file system, and deployment model can all change at the same time. Checking dependencies early makes template migrations more predictable and helps keep generated documents consistent across servers. ### Frequently Asked Questions What does the template dependency checker validate? ---------------------------------------------------- It loads a TX Text Control template and reports missing runtime dependencies such as unavailable fonts and missing linked image files. When JSON data is provided, it also reports data fields, merge blocks, block fields, and form field names that are not represented in the document. Why is this useful when moving from Windows to Linux? ------------------------------------------------------ Windows and Linux servers usually have different fonts installed. A template designed on Windows can use fonts that are not available in a Linux container or server. The checker uses TX Text Control font adaptation events to list fonts that are missing in the target runtime. Does the checker compare the document against JSON or JSON against the document? --------------------------------------------------------------------------------- The JSON data source is treated as the expected contract. The checker lists JSON fields and blocks that are missing in the document. This helps verify that a template consumes the data object the application will provide. How are merge blocks detected? ------------------------------- Merge blocks are detected from TX Text Control SubTextPart names that use the internal merge block prefix txmb\_. For example, a SubTextPart named txmb\_lineItems is treated as a merge block named lineItems. How does dot notation work? ---------------------------- A JSON field such as customer.name can match a merge field named customer.name. It can also be satisfied by a merge block named customer and an inner merge field named name, which reflects common TX Text Control template structures. Should this replace template testing? -------------------------------------- No. It is a preflight check. It helps find missing dependencies before document generation, but applications should still run full merge and rendering tests with representative data and output formats. --- ## About Bjoern Meyer As CEO, Bjoern is the visionary behind our strategic direction and business development, bridging the gap between our customers and engineering teams. His deep passion for coding and web technologies drives the creation of innovative products. If you're at a tech conference, be sure to stop by our booth - you'll most likely meet Bjoern in person. With an advanced graduate degree (Dipl. Inf.) in Computer Science, specializing in AI, from the University of Bremen, Bjoern brings significant expertise to his role. In his spare time, Bjoern enjoys running, paragliding, mountain biking, and playing the piano. - [LinkedIn](https://www.linkedin.com/in/bjoernmeyer/) - [X](https://x.com/txbjoern) - [GitHub](https://github.com/bjoerntx) --- ## Related Posts - [Speed Up Document Generation by Factor 2 Using Selection Objects in .NET C#](https://www.textcontrol.com/blog/2026/07/17/speed-up-document-generation-selection-objects-dotnet-csharp/llms.txt)