I never took the time to look at the EventLog implementation before. Coming from the C++ / Win32 world, I know there's a lot missing in the .NET EventLog class, such as the replacement strings and the use of the .mc (message compiler) file, etc.

Today, I decided to look into it a bit more, checking out what needs to be registered for my custom event log source messages to be viewed correctly.

When you call EventLog.CreateEventSource, (which I know you don't have to call, but the runtime does this for you when you first call EventLog.WriteEntry) it registers EventLogMessages.dll (from the .NET install dir) as the message file. See registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\Application\YourEventSourceName

EventLogMessages.dll is the hack. It has the message file resource, and 65,535 entries, all with %1 as the message. So when you write a message via WriteEntry, it takes the entire string that you provide, and stores that as replacement #1.

Lame because:

1. entire message is stored instead of ID and replacement strings, so takes up much more space.
2. when READING the event log, you don't get the localized version of the message, you get what was created at runtime, since it's the only replacement string available.

In a news post I was reading somewhere, they were guessing that this is a hold over from the VB6 code - since that's pretty much exactly what VB6 does for event log messaging. Ugh.

Here's an article where a guy comes up with a replacement for EventLog class.

The Code Project - Enhanced EventLog writing for .NET Applications - C# Programming