[Mono-dev] local file based EventLog implementation

[Gert Driesen]

> -----Original Message-----
> From: mono-devel-list-bounces at lists.ximian.com [mailto:mono-devel-list-
> bounces at lists.ximian.com] On Behalf Of Kornél Pál
> Sent: donderdag 17 augustus 2006 21:15
> To: Gert Driesen
> Cc: mono-devel-list at lists.ximian.com
> Subject: Re: [Mono-dev] local file based EventLog implementation
> 
> Hi,
> 
> >I do intend to support this for win32 using your supplied
> >EventLogMessages.dll by default, and third-party message resource
> dll's
> >when these are registered.
> >
> >I just wondered whether there's a something similar to these message
> >resource dll's for unix. With this we could also support lookup of
> >messages from a resource file, and perform placeholder replacement on
> >unix. This would allow localization of eventlog messages, like we have
> >on windows (if third parties provide localized message resource dll's
> >for their eventlog sources).
> >
> >We could ofcourse use managed resource assemblies for this purpose on
> unix.
> 
> > You can't use Windows API on Unix but you were talking about all the
> > time.
> > Everything I said is about the Windows API.
> 
> No message DLL can be registered using the class library so there is no
> need to message DLL support on non-Windows operating systems.

See below. It is possible in .NET 2.0.

> If you want such support you have to implement it using registry and
provide
> some compatible support but I don't think that it makes much sense.

I will indeed implement it using the registry on Windows, but on linux we
could just use an XML file (or flatfile, ...) to store this information.

> >> A EventLogMessages.dll is required if you want to use the Windows
> API.
> >It is not strictly required, but it would be better if we indeed use
> it.
> 
> On Windows it is required. OK, it can have any name but Windows API
> requires a message DLL and no message DLL can be specified using
> managed API so this is transparent to managed applications.

It is not required. I have it working perfectly fine without one.

> The purpose of a message DLL is probably to support multi-lingual user
> interface and/or to save disk space.

Yeah, both.

> But the managed event logging API
> has no support for this because it requires a message text rather than
> a message DLL and a message ID. Event ID is stored but does not affects
> the message used.

This is supported in .NET 2.0 by using EventLog.WriteEvent overload.

Also, the CreateEventSource overload that takes an EventSourceCreation
instance supports setting a custom message DLL.

> If you want strict Windows-like logging using registry then you may
> want to consider using the same .evt file format that is used by
> Windows. (But I think a correct implementation of the managed API don't
> has to be Windows compatible as well.)

Nope, on Windows we use the win32 API while on linux we will be using a
simple file store.

I would definitely have been possible to use the same format on unix (and
not hard to implement), but I don't see much additional value in this. I
don't think people will be copying these files over.

Unless we would stop using the win32 API to read/write event entries on
Windows, it would not make any sense.