Sapporo

The alternate way of getting the apppath does work as I just checked it. System.Reflection.Assembly.GetExecutingAssembly.Location returns "d:\#dotnet\vocompusageserver\bin\vocompusageserver.exe" System.IO.Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly.Location) returns "d:\#dotnet\vocompusageserver\bin"

Are you sure? I don't import Windows.Forms in my service and it writes a log file to c:\ (hardcoded) without any problems. btw, my logwrite function is similar to yours, except I open the file with .AppendText instead. As to the path question, I'll have to dink around with that when I get into work tommorrow. There has to be a way to get it without a dependency on Windows.Forms and is suitable for use in a service. Another to note is that the working folder for a service maynot be what you expect it to be. I wouldn't be suprised if it always showed up as c:\winnt\system32 or something. UDP seems to be performing fairly well, but I haven't rolled out the solution quite yet. It will eventually be installed on 1500 computers and what it does is track idle/active intervals and reports it to a stats server. Basically, if there was any input in the last 5min interval it will report "active" otherwise it sends "idle". The actual UDP packet contains the computer name, interval time, and status. This information is then going to be used for future budgeting decisions. So if a dept asks for more computers we can come back and say "You have 20 computers that are on average idle 6 hours a day. Why do you need more?" Anyways, I have the client service installed on around 50 computers so far and they have been sending stats to the server service for the last 2 months now without fail. The only thing preventing me from doing the final roll out is waiting on Operations next phase.

I saw your readme and I don't think you should import System.Windows.Forms as your writing a service and not an interactive app. I would try something like this first for getting the AppPath: System.Reflection.Assembly.GetExecutingAssembly.Location As to your problems with TCP, I don't know what to tell you. I've only used UDP in the service that I wrote and haven't had a chance to play with TCP in vb.net yet.

I just came across a rather annoying bug (VB.NET) that has to deal with the autoscroll feature on forms. How to reproduce the bug: 1. Create a form 2. Add any control (I used button) 3. Add any control (I used a textbox set to multi-line) 4. Set the Form.AutoScroll = True 5. Resize the form in the design view so that it will cut the second control in half. The scrollbar should now be visible. 6. Ensure that the first control will have focus when the form loads (tabindex = 0) 7. Run the project. You should see that the first control has focus and the second control does not get drawn at all. It will literally be a screen artifact of what is under the form. The 2nd control will not be drawn even if you maximize the form or resize it. You have to invalidate the entire form for the control to be drawn (like minimize and restore, or move a dif app window over it). Any suggestions on how to fix this?

Ok, I misread your post and my reply is basically a tangent :)

I agree that a Service is not what you want to use for this. A Service is designed for background tasks that don't require a user to even be logged into the system at all (it could be sitting at the login prompt and the service would work). Also, a Service typically runs under the System account and therefore is "userless" and thus has no Domain privileges. You can run a service under a domain account, but I don't think this is what you want to do. Since your whole project revolves around Outlook. Why not use Outlook to accomplish the task? To me it sounds like you will have a user logged into the workstation with Outlook open so why not take advantage of the Outlook Rules? I would check out the "Custom Action" that Outlook has for processing Rules. It allows you to write your own DLL and have Outlook link to that DLL to run your custom action. As to wether you can do this with .NET is questionable (no personal exp here). You might also check out the "start application", as you could possibly have it launch a program that would then link to Outlook and do it's processing from there (either thru automation or a direct exchange connection). Since your using the Rules engine you can have the rule fire when a new message arrives and add additional standard criteria like who it's from or a phrase in the email itself.

This question is along the same line. I just finished coding a simple service in VB.NET. All the service does is receive UDP packets and write them out to a file. This service is used to collect stats on computer usage for reporting purposes. There is a client service that sends the UDP stat packets back to the master service. Anyways, when started this service takes up 8.3Mb of memory with an additional 4.5Mb of Virtual Memory. I do not know if it "grows" over time, but I seriously doubt it. btw, the service is coded in VB.NET and is around 30 lines of code with the following imports: Imports System.ServiceProcess Imports System.IO Imports System.Net.Sockets Imports System.Text.Encoding Imports System.Threading Is this the smallest memory footprint you can get with .NET (or specific to VB.NET) ??