[Mono-dev] local file based EventLog implementation
gert.driesen at telenet.be
Thu Aug 17 15:24:23 EDT 2006
> -----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
> >I do intend to support this for win32 using your supplied
> >EventLogMessages.dll by default, and third-party message resource
> >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
> > 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
> 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
> >It is not strictly required, but it would be better if we indeed use
> 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.
> 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.
More information about the Mono-devel-list