Native Libraries and Architecture Mismatches
The document engine of TX Text Control is a set of native Windows libraries, one set for 32-bit and one for 64-bit processes. The .NET assemblies are the same for both, and they load the native set that matches the process. When that set is missing, belongs to the other bitness, or lacks the Visual C++ runtime it needs, the application fails as soon as the engine starts. 32-bit and 64-bit Applications explains the two sets.
The Kernel DLL File Could Not Be Found
Creating a TextControl or ServerTextControl fails with this message:
The TX Text Control kernel DLL file could not be found.
The native libraries for the bitness of the process aren't where TX Text Control looks for them. In a .NET Framework application, the files of Assembly\bin are for 32-bit processes and those of Assembly\bin64 for 64-bit processes, and all files must be in the folder of the executable. An AnyCPU application runs as a 64-bit process on 64-bit Windows, so it needs the 64-bit set there.
- Decide on a bitness and build for it, as the next section shows, or deploy the set that matches the host of an AnyCPU application.
- In a .NET Framework application, copy the native libraries of Assembly\bin for x86 or Assembly\bin64 for x64 into the folder of the executable, next to the managed assemblies.
- In a .NET 8 or later application, publish with a target runtime, such as
win-x64; see A Published .NET Application Lacks the Native Libraries.
The Application Runs With the Wrong Bitness
The application runs on some machines and fails on others with the message of the previous section, or it works in Visual Studio and fails when it is deployed.
An AnyCPU build takes the bitness of the host, so the native libraries it needs depend on the machine. Build for x86 or x64 instead, and deploy the native libraries of the same bitness: Create x86 and x64 Configurations in Visual Studio shows the steps, and x86, x64, and AnyCPU the files each platform deploys.
The Visual C++ Runtime Is Missing
The application fails on a machine where it wasn't developed, while all files of TX Text Control are deployed.
TX Text Control .NET for WPF uses the Microsoft Visual C++ runtime file VCRUNTIME140.DLL, which not every Windows installation has.
- Install the Visual C++ Redistributable Packages for Visual Studio 2017 on the target machine, in the bitness of your application: 32-bit for x86 builds, 64-bit for x64 builds.
- Include the redistributable in the installer of your application, as Visual C++ Runtime Dependencies describes.
The Files of an Earlier Version Are Deployed
After an upgrade, an installer or a deployment script that lists the files by hand fails to deploy the native libraries, or the application starts with the files of the previous version. The format filters, such as tx34_pdf.dll, carry the major version in their names, and since version 33.0 the core libraries do too: tx33.dll, tx33_tls.dll and tx33_ic.dll replaced txkernel.dll, txtools.dll and txic.dll. An Installer Doesn't Include the Files of TX Text Control lists the new names and how to update the file list.
Create Returns False
ServerTextControl.Create returns false, and using the instance fails with this message:
The TXTextControl object must have been completely loaded to use this method.
Create returns false when no new window handle can be created, usually because instances that were never disposed hold the handles of the process. The TXTextControl Object Must Have Been Completely Loaded lists the fixes.