Codecore Logo
Quick Search
Advanced Search »

Client Configuration File

This document is OBSOLETE and superceded but the Machine Settings Tool.

This xml formatted file and each of it's parameters are optional, however if there is an xml syntax error within the file it usually results in the application or service failing to start.

The client configuration file is NOT encrypted.

Changes to the configuration file won't take effect until the applications are restarted (the master service and driver services need to be recycled).

The file can be manually edited with a text editor or with the Client Configuration Tool.

File Location

The ClientConfig.xml file is located in the Codecore Technologies\Elve directory within the Common Program Data Folder, on a computer having any of the application installed.

  • Windows Vista/7 path example: C:\ProgramData\Codecore Technologies\Elve\ClientConfig.xml
  • Windows XP path example: C:\Documents and Settings\All Users\Application Data\Codecore Technologies\Elve\ClientConfig.xml

Default Values

A default value is used when the associated parameter (xml element) is not specified in the file or when the file does not exist.

MasterServerHostName: localhost
WellKnownLocalHostName: blank
BindToIPAddress: blank
LoggingVerbosity: Normal
WebServerRootDirectoryPath: %CommonApplicationData%\Codecore Technologies\Elve\WebSite
WebServerPort: 80
MasterServicePort1: 33900
MasterServicePort2: 33901
DriverServicePort1: 33902
DesktopServerPort1: 33903
MasterServicePort3: 33905
DesktopServerPort2: 33906
TouchServicePort1: 33907
MaximumLogSize: 20971520 (20MB)


The hostname or ip address of the Master Service machine which client applications will use when connecting to the Master Service.

This is normally only set on machines running Elve applications and services other than the Master Service, however if the BindToIPAddress setting is set on the Master Service machine then MasterServerHostName should usually match it since some Master Service listeners will only be listening on the BindToIPAddress address.


This is normally only used when you have multiple network interface cards or multiple IP addresses in a machine.

The WellKnownLocalHostName is the local hostname or IP address that will be used by remote applications and services to talk back to the client application or service. An example of this would be when the Touch Screen Viewer application connects to the Master Service, Touch Screen Viewer tells the Master Service it's WellKnownLocalHostName and in some cases the Master Service may need to initiate a new connection back to the Touch Screen Viewer using the hostname or IP address specified in the WellKnownLocalHostName setting.

If WellKnownLocalHostName is not set then the local machine's DNS name will be used. Be sure that the local machine can be reached by the remote Elve applications and services using this name.

It is generally a good idea to use the Domain Name System (DNS) name of the local computer, but when the IP Address for a particular network interface card (NIC) (usually a wireless NIC) is changing rapidly, you must configure the application to use the WellKnownLocalHostName to enable finding the machine through DNS. However, when the computer name does not resolve with reasonable speed (if at all) and when the computer has more than one NIC, either physical or virtual (this is often the case with a dial-up connection or VPN network adapter), you should set the WellKnownLocalHostName setting to the IP address of the NIC that is currently in use for that connection.

You will need to set this when:

  • When running an application (such as Elve Management Studio or Touch Screen Viewer) on a difference computer than the master service you may need to set this setting.
  • The client machine has multiple IP addresses or you are using NAT between the 2 machines.

If WellKnownLocalHostName setting is not correct then you will see a message in the log that looks something like the following message. Notice the port # is not one of the standard Elve ports from 33900 to 33907 which is usually an indication of a failed callback connection due to an incorrect WellKnownLocalHostName.

ScriptEvaluatorException: An unknown error occurred while evaluating the script. SocketException: No connection could be made because the target machine actively refused it
SocketException SocketErrorCode: ConnectionRefused

If you set the WellKnownLocalHostName setting you should review the BindToIPAddress setting description to see if it is also applicable.

Here's an example of setting the WellKnownLocalHostName value in the ...\Codecore Technologies\Elve\ClientConfig.xml file:

<?xml version="1.0" encoding="utf-8" ?>


This is normally only used when you have multiple network interface cards (physical and/or virtual) in a machine and you need to tell Elve which network interface card should be used for outgoing network traffic from Elve and in some cases incoming traffic. If you have multiple network interface cards in a machine and you do not specify this setting then Elve will use the NIC with the highest priority for outgoing traffic and will listen for incoming traffic on all NICs.

Set BindToIPAddress to the IP address of a network interface card that all Elve applications and services should bind to on the local machine (with the exception of device drivers which use tcp, they will bind to the highest priority NIC for outgoing traffic unless the driver developer chooses otherwise).

Technically speaking, this is the local endpoint ip address on the local machine that Elve uses to send data out to the network and in some cases listen on.

If you set BindToIPAddress you may also need to set the WellKnownLocalHostName appropriately so that callback operations from the remote host can find the local NIC that initiated the original connection.

LoggingVerbosity values

Normal is the recommended setting for typical usage.

  • Quiet : Nothing will be logged.
  • Minimal : Errors and Fatal events will be logged.
  • Normal : Warnings, Errors, and Fatal events will be logged.
  • Detailed : System Messages, Warnings, Errors, and Fatal events will be logged.
  • Diagnostic : No log filtering is done, everything gets logged.


The maximum size that the log may grow to in bytes. The system will automatically remove older records to ensure the file does not exceed this size.

Example File

<?xml version="1.0" encoding="utf-8" ?>
Privacy Policy | Conditions Of Use

Copyright ©2014 Codecore Technologies, All rights reserved.