Hi Warren,
I am sorry to hear that you are having challenges with utilizing CodeSite for your products, but I do value your feedback. There are certainly limitations to the way CodeSite is currently designed with respect to services. This wasn’t always the case, but the fact is that logging from services with the current version of CodeSite is challenging because of the increased isolation that Microsoft has added to Windows.
When it comes to using CodeSite in a service, it all comes down to deciding how to run the CodeSite Dispatcher. There are two choices: 1. run the Dispatcher as a service, 2. run the Dispatcher as a desktop app. While it may appear that only option 1 is valid, but this not necessarily true. Each option has its advantages and disadvantages.
Running the Dispatcher as a service does make it a little easier for the CodeSite logging classes to communicate with the Dispatcher because the default transport method (wm_CopyData) can be used. Also, the Dispatcher service can be running even when no user is logged into the system. However, with the Dispatcher running in the service window station it is NOT possible to do Live Logging with the Dispatcher running as a service. That is because Windows prevents the Dispatcher from transporting CodeSite messages to the Live Viewer running on user’s desktop.
Running the Dispatcher as a desktop application will allow you to conduct Live Logging even from service apps. However, in order to do this, the transport method the CodeSite logging classes use to send their messages to the Dispatcher must be changed from wm_CopyData to TCP. This is accomplished by calling the ConnectUsingTcp() method either on the CodeSiteManager, or on the individual TCodeSiteLogger objects in your app. TCP messages are allowed to cross window station boundaries and thus the CodeSite Dispatcher will be able to receive CodeSite messages and then dispatch them to the Live Viewer and of course log files. Of course, in order for the Dispatcher to receive the TCP CodeSite messages, the appropriate port must be opened. Some customers have run into challenges in getting ports opened in a production environment for “logging”.
The reality is that in today’s environments, logging from services really is best served with the ability to allow the service itself to be able to log CodeSite messages directly to an isolated log file without requiring coordination from an external application. It should still be possible to send CodeSite message remotely, if desired, but again, it should all be handled within the service itself. This is, in fact, one of the major design goals I have been using while working on the next major release of CodeSite. I wish I could provide more concrete info and a release date, but I’m not ready to do that just yet.
In regards to item 3 in your list, I am intrigued by your comments. The Live Viewer has always been the primary developer tool for “debugging”. It was never intended to be used as a kind of CodeSite dashboard. But perhaps a CodeSite Dashboard is something that you would be interested in? I suppose a “Dashboard” mode could be added to the Live Viewer, but I’m wondering if it would be better to have a dedicated app. I am interested in learning more about how you are logging on non-developer machines. The Live Viewer is included in the CodeSite Tools as a convenience for on-demand Troubleshooting and not the usual method for capturing logging data–most end users do NOT want to see a logging window. Are you conducting File Logging along with Live Logging in your apps?
In regards to item 4, it is possible to send CodeSite messages to remote computers. This involves setting the CodeSiteManager.DefaultDestination or the Destination property of an individual CodeSite logger. The CodeSite Help does provide information on how to setup the subproperties of the destination properties. The key is that the CodeSite Dispatcher needs to be running on the local machine AND the remote machine.
I hope this helps answer some of your questions and concerns, and thanks again for your feedback.
Ray