[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 Robert Jordan
> Sent: vrijdag 18 augustus 2006 16:19
> To: mono-devel-list at lists.ximian.com
> Subject: Re: [Mono-dev] local file based EventLog implementation
> 
> Gert Driesen wrote:
> > b) adding EventLogMessages.dll to the binary distributions (for
> win32,
> > and linux too)
> >
> > If we do not get approval for (b) (not sure why, but could be
> > ofcourse), then we could still embed the dll into the System assembly
> > and extract it at runtime (if it doesn't exist yet).  But I'd rather
> avoid this.
> 
> The Debian folks usually don't accept binaries. I wish you good luck to
> explain them the difference between a managed DLL, an unmanaged DLL and
> an unmanaged DLL consisting of just one PE resource :-)

I think it would indeed be better to either build it at compile time, or if
is too difficult to achieve (especially on linux) that we can always embed
it. Or as a (very) last resort, do not register one for event sources
created from Mono.

> > In what form should EventLogMessage.dll added to svn (and the source
> > distributions) ? Can we juist include it as is, or do we need to
> build
> > it at compile time ?
> 
> Please excuse my ignorance, but why on earth do we need
> EventLogMessage.dll with its PE resources under Unix?

It's definitely not needed, but Kornél proposed to use it on unix too.  IT
would be nice to have, but not necessary.

On Windows, I think we should definitely use it. But there it's also not
strictly necessary (but more than one unix).

> I understand why it's needed for Win32 and even why
> Win32 demands it (performance and log file size optimization), but
> since MS.NET installs EventLogMessage.dll, no one will ever use
> resource DLLs with .NET, IMO. No one wants to deal with MC and RC just
> for eventlogging's sake.

In .NET 2.0, MS provided better support for using message resource dll's, so
I'm pretty sure its usage will pick up.

Reading event entries created by event sources that use a message resource
has already been implemented (for the win32 implementation).

Gert