[Mono-dev] local file based EventLog implementation
kornelpal at gmail.com
Sun Aug 20 13:01:11 EDT 2006
>> > b) adding EventLogMessages.dll to the binary distributions (for
>> > 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.
Mono is only "copied" by Debian folks so I think we don't have to explain
them anything.:) Along with EventLogMessages.dll I posted a batch file that
builds EventLogMessages.dll. I think that there are open scource build tools
that can do the same so building is not a big deal but those tools are not
likely to be installed on non-Windows operating systems. If you are really
freaking binaries it's quite easy to write a managed exeutable that will
generate it.:) But as this is not a code module you should think of it more
like a .png image than a .dll library. Or if you prefer it even can be a
managed assembly that has the appropriate unmanaged resources but that way
it will become a file containing code as well.
>> > 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
>> > 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).
For Windows: Windows event log requires a message DLL. If you can provide a
simple test case (that calls Windows API directly) that show that no message
DLL is required I believe you otherwise I cannot because all my experiences
and even Platfrom SDK documentation is clear that the messages are read from
If I don't set (or delte)
I get the following error message in Event Viewer:
The description for Event ID (...) in Source (...) cannot be found. The
local computer may not have the necessary registry information or message
DLL files to display messages from a remote computer. You may be able to use
the /AUXSOURCE= flag to retrieve this description; see Help and Support for
details. The following information is part of the event: ...
So strictly speaking it works (because the function calls succeed) but as
you can see you will see no message when you use no message DLL. So I think
message DLL dependency can hardly be named not strictly necessary because
the message is an esential part of an event log entry.
For Unix (and others):
Because you are going (or already done) to implement message DLL handling on
Unix (according to your previous messages using registry) as well I think
it's quite obvious to use EventLogMessage.dll as well. If it's OK for you to
use registry on Unix I don't see any reason not to use EventLogMessage.dll
as well because message DLL can be read and written using registry methods
and the no message DLL situation should have the same result as on Windows.
>> 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,
>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).
If you want to implement message DLL support on non-Windows operating
systems you should use PE files as well because otherwise it will be
incompatible with MS.NET for no reason. Managed modules are PE files so they
can containt PE resources and it somebody uses it's own executable or some
bundled DLL as messages, event logging will simply not work on non-Windows
operating systems for no reason, because it contains no native code.
As for EventLogMessage.dll: We don't need it. But we need a PE file with the
same message resources. And I think it's quite easy to use the same file
name and it improves compatibility as well so I don't see any reason to put
these resource to System.dll for example instead.
Gert: If you send me your latest patch I'll have a look at it.
More information about the Mono-devel-list