x86, x64, and AnyCPU
x86, x64 or AnyCPU is a build setting in Visual Studio, but for a WPF application with TX Text Control it is also a deployment decision. The platform fixes the bitness of the process, and the bitness fixes which of the two sets of native libraries has to be on the user's machine. Read on for the files each platform needs, for publishing a .NET application for one platform and for the same choice in .NET Framework projects.
Platforms and Their Files
The managed assemblies, including TXTextControl.WPF.dll, are the same for x86, x64 and AnyCPU. What follows the platform is the set of native libraries, whose folders in the package and the setup are listed in Native Libraries, and the bitness of the Visual C++ runtime. Which set and target runtime each platform needs, how each one runs and which one to choose is explained in Choose a Build Configuration.
Publish a .NET Application for One Platform
For a .NET 8 or higher application, the target runtime of the publish decides which native libraries end up in the output: win-x86 puts the 32-bit set next to the executable, win-x64 the 64-bit set, and a publish without a target runtime leaves both sets in runtimes subfolders. Publishing .NET Applications shows how to set it in Visual Studio and with dotnet publish -r.
Deploy a .NET Framework Application for One Platform
In a .NET Framework project, you copy the native libraries of the platform yourself: Assembly\bin for x86, Assembly\bin64 for x64, and for AnyCPU the folder that matches the bitness of the target machine. The Folders of the Setup describes all files and what an AnyCPU installer has to do.
Mismatched Bitness
If the process doesn't find native libraries of its own bitness, TX Text Control can't start its engine, and creating the TextControl fails. This happens, for example, when an AnyCPU application runs as a 64-bit process where only the 32-bit set was installed. Native Libraries and Architecture Mismatches has the messages and the fixes.