by Raize Support » Mon Oct 21, 2013 5:19 am
Hi Eric,
First of all, in the configuration that you have, there is no real need to have the TCP destination type. The destination is the same computer, and it not gaining you anything.
To understand this, it would be helpful to understand the communication path a CodeSite message takes. Basically, there are 2 steps in the communication process. The first step is between your application code and the CodeSite Dispatcher. The default method for this communication channel is wm_CopyData, which is very fast and lightweight. However, wm_CopyData cannot be used to cross window-station boundaries. This is an issue when you have service applications and the Dispatcher is running as a regular application. That is, the Dispatcher is running in a different window-station. In this case, the ConnectUsingTcp method must be called to instruct the TCodeSiteLogger instances to send their CodeSite messages to the Dispatcher using TCP.
The second communication channel is between the CodeSite Dispatcher and the Destination(s). This is where the TCodeSiteDestination is used. The Dispatcher uses the Destination properties to determine what to do with the messages. If a log file is specified, then the Dispatcher saves the message to the log file. If the Viewer is specified, the message is sent to the Live Viewer. If TCP is specified, the current (local) dispatcher sends the message to a remote dispatcher. (In your code, the remote dispatcher is the same as the local one). When using TCP, the remote dispatcher uses the RemoteDestinationDetails property to determine what to do with that message.
Going back to your original post, what specifically do you mean by "Whatever I try no more message after ServiceExecute come in the file"?
Also, what version of Windows are you using? And, what type of application is generating the CodeSite messages? That is, is it a service application, or a regular desktop app?
Ray