help logging events to txt file

[cj]

I'd like some advise on a fool proof logging system. I have a windows
app and need key events to be logged to a text file. Here are the
REQUIREMENTS I have been given--generally requirements I'm given are
non-negotiable.

--It might be hours or days between logging events or just split seconds.

--This application will be run from a network drive and the log file
will reside in the directory it is run from.

--This same exe will be run on multiple pcs at the same time and mabye
even run multiple times on the same pc. All running instances of this
app running must use the same log file.

--The log file is to be appended to.

--The log file must be able to be opened in notepad while it's being
written to. I understand opening it will only show me what's in it at
the moment it's opened.

--Trying to write to the log file must never stop the program from
running (well more than a couple of seconds). If worst come to worst
and an event can not be logged in a couple of tries don't log it.

Can anyone give me any ideas on how to do this?

I see potential problems with more than one instance of the app trying
to write at the same time and also with the file being open in notepad
when an app tries to write to it. On the up side the longest lines
being written will be exception.message text returned if an error occurs.

[Göran Andersson]

If you try to open the file for writing from more than one program, you
will get an exception. You would have to catch and identify that
exception so that you can try to open the file again, preferably after a
short delay.

You should record the time before the first try, and/or count the number
of retries, so that the program can give up after a reasonable time
and/or number or retries.

Reading from the file while it's being written to should be no problem,
but the last record may show up partially written. I believe that the
default share mode when opening for append is read, but if it's not you
would have to specify that.

cj wrote:

I'd like some advise on a fool proof logging system. I have a windows
app and need key events to be logged to a text file. Here are the
REQUIREMENTS I have been given--generally requirements I'm given are
non-negotiable.

--It might be hours or days between logging events or just split seconds.

--This application will be run from a network drive and the log file
will reside in the directory it is run from.

--This same exe will be run on multiple pcs at the same time and mabye
even run multiple times on the same pc. All running instances of this
app running must use the same log file.

--The log file is to be appended to.

--The log file must be able to be opened in notepad while it's being
written to. I understand opening it will only show me what's in it at
the moment it's opened.

--Trying to write to the log file must never stop the program from
running (well more than a couple of seconds). If worst come to worst
and an event can not be logged in a couple of tries don't log it.

Can anyone give me any ideas on how to do this?

I see potential problems with more than one instance of the app trying
to write at the same time and also with the file being open in notepad
when an app tries to write to it. On the up side the longest lines
being written will be exception.message text returned if an error occurs.

[jayeldee]

I did something similar to this in an old project where upwards of 30
instances of my application had to retrieve a password from the
database then mark a bit field that the password was in use. Due to
the nature of the application, they were all starting up at roughly the
same time, so I used a COM Exe (this was in vb6) with one object that
had a GetPassword and ReleasePassword function.

I'm not 100% sure on what the .NET equivalent would be, but some kind
of remotable singleton class may do the trick.
http://msdn.microsoft.com/library/de...toremoting.asp
seems a good place to start.

This would take all the bother of synchronization and clashes out of
your windows app and let it be handled in one process.

I'll admit I haven't messed with this kind of work much in .NET so
somebody else may have better options.

john