When you create an application using the SocketTools .NET Edition components and you’re ready to deploy it, you must ensure it is initialized correctly. This is done by either providing a runtime license key to the Initialize method, or setting the RuntimeLicense attribute for the executable assembly. It is important to note your runtime license key is not your product serial number.
If you have an evaluation version of SocketTools, you will not be able to redistribute your application until you have a runtime license key. During the evaluation period, your software will only work on the development system where SocketTools has been installed. After you’ve purchased a development license, you’ll be able to create a runtime license key and redistribute your application.
Important: This article provides information for a version of SocketTools which is no longer supported. It is recommended you upgrade your project to use the current version.
After you’ve created an instance of the SocketTools .NET class, call the Initialize method and pass the runtime license key string as its argument. You should always check the return value from the Initialize method to ensure the class instance has initialized correctly.
You can generate the runtime license key using the License Manager utility included with SocketTools. Select License | License Key from the menu to display the runtime license key, or use License | Header File from the menu and then choose your language from the dropdown list to generate a file which contains the key.
Additional information about runtime licensing can be found in several places in the documentation, including the Licensing Information section, Class Initialization in the Developer’s Guide and the Initialize methods in the Technical Reference.
When SocketTools is installed on your development system, the installer will check for the latest version of Visual Studio on the system and automatically configure itself to use the correct assemblies for that version. For example, if you have both Visual Studio 2008 and 2012 installed on the same development system, the SocketTools installer will configure your system to use the .NET Framework 4.5 assemblies by default. If your project uses an earlier version of the .NET Framework, you can explicitly reference the appropriate version you require.
When redistributing your application to another system, make sure you include all of the assemblies you’re using in the same folder as your application. The SocketTools assemblies can be found in:
C:\Program Files (x86)\Common Files\Catalyst Shared\v8.0\Assemblies
If your application is targeting .NET Framework 4.5 or later, then you should use the assemblies in the v4.5 folder. If you are using an older version of Visual Studio, then you should select the assemblies which match the version you’re using. If you’ve installed SocketTools on 32-bit Windows, they will be found under C:\Program Files\Common Files instead of C:\Program Files (x86)\Common Files.
Although the assemblies are installed under Program Files (x86) on a 64-bit Windows system, they are platform neutral and can be used with either x86 and x64 applications. Only the SocketTools .NET interop libraries target a specific platform.
SocketTools Interop Library
In addition to the SocketTools assemblies, you must also redistribute the SocketTools .NET interop library. If you are deploying your application to a system running the 32-bit version of Windows, you should install the 32-bit version of the SocketTools8.Interop.dll library in the \Windows\System32 folder.
If you are deploying your application to a system running the 64-bit version of Windows, you should install the 32-bit version of the interop library in the \Windows\SysWOW64 folder, and the 64-bit version of the library in the \Windows\System32 folder.
If you are using the Trace (debugging) related properties in your application, you should also include SocketTools8.TraceLog.dll library in your installation package and install it in the same folder as the interop library.
Your installation software should always perform version checking to ensure it’s not overwriting a newer version of the interop library with an older version. If the software you’re using (e.g.: InstallShield) creates a 32-bit executable and you’re deploying a 64-bit application, the installer must be capable of detecting it’s running on a 64-bit system and can disable filesystem redirection to ensure the 64-bit libraries are installed in the correct location. Consult the documentation for your installation software to determine if it’s 64-bit compatible.
Redistributable versions of the SocketTools .NET interop libraries can be found in:
C:\Program Files (x86)\SocketTools 8.0 .NET Edition\Redist\x86 (32-bit)
C:\Program Files (x86)\SocketTools 8.0 .NET Edition\Redist\x64 (64-bit)
If you installed SocketTools on 32-bit Windows, the default installation will be in C:\Program Files instead of C:\Program Files (x86). If you changed the default installation path, then the Redist folder will be found where you installed SocketTools.
To help simplify deployment, we’ve created MSI (Windows Installer) packages you can use to install the SocketTools .NET interop libraries on end-user systems:
If you’re redistributing a 32-bit application, then all you need is the x86 installer package. If you’re redistributing a 64-bit application, then you need the x64 installer package. If your application is built to target both platforms, then you will need both x86 and x64 packages. The installer packages will make sure the interop libraries are installed in the correct location and will perform the appropriate version checking.
If you have your own installer for your software, then you can redistribute those MSI packages with your installation and use the msiexec command to perform the installation. For example, this would install the 32-bit interop DLL with no UI displayed:
msiexec /qn /I cstools80_interop_x86.msi
For the complete list of command line options for msiexec, refer to