[Mono-dev] local file based EventLog implementation

[Kornél Pál]

>> > 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.

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
>> 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).

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 
a DLL.
If I don't set (or delte) 
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\Application\<source>\EventMessageFile 
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, 
>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).

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.

Kornél