Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Writing to the Event Log
It’s interesting how something might exist for a while and then be given a nom de guerre (literally, "name of war," a name for a role), and then the thing takes on a new buzz and official importance. Writing to the event log is part of what’s now referred to as instrumenting your code.
In this context, instrumenting means that we’ve added code for recording, measuring, or controlling what goes on in an application. The new "official" name makes instrumenting sound important, and it is, but it has always been important. Listing 3 demonstrates how easy it is to record what goes on in your code by using an event log write. (See Figure 1 for the event log entry, and be sure to read the paragraphs after the listing for important required steps.)
Listing 3 Instrument your code with writes to the event log.
<Security.Permissions.FileIOPermission(Security.Permissions.SecurityAction.Demand)> _ Sub WriteEventLog() My.Application.Log.WriteEntry( _ "Welcome to Valhalla Tower Material Defender!", TraceEventType.Information) End Sub
)
Figure 1 The event log entry as it appears on my laptop after running the code in Listing 3.
Generally, with the event log we must specify information such as the event source and log to which we want to write. But because the My feature doesn’t have a parameter for details such as source and machine, we have to provide this information somewhere. Wanna guess? The answer is that we provide log-specific information declaratively in the sharedListeners section of the App.config file, as shown in Listing 4. The entries that support writing to the event log are shown in bold.
Listing 4 Adding a listener and the source name, MyFeature.
<?xml version="1.0" encoding="utf-8" ?> <configuration> <system.diagnostics> <sources> <!-- This section defines the logging configuration for My.Application.Log --> <source name="DefaultSource" switchName="DefaultSwitch"> <listeners> <add name="FileLog"/> <!-- Uncomment the section below to write to the Application Event Log --> <add name="EventLog"/> </listeners> </source> </sources> <switches> <add name="DefaultSwitch" value="Information" /> </switches> <sharedListeners> <add name="FileLog" type="Microsoft.VisualBasic.Logging.FileLogTraceListener, Microsoft.VisualBasic, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" initializeData="FileLogWriter"/> <!-- Uncomment the section below and replace APPLICATION_NAME with the name of your application to write to the Application Event Log --> <add name="EventLog" type="System.Diagnostics.EventLogTraceListener" initializeData="MyFeature"/> </sharedListeners> </system.diagnostics> <applicationSettings> <MyFeature.My.MySettings> <setting name="data" serializeAs="String"> <value>This is some string data</value> </setting> </MyFeature.My.MySettings> </applicationSettings> </configuration>
The EventLog feature uses a trace listener. In this case, the EventLogTraceListener is loaded dynamically and the initializeData attribute contains the EventLog source information.
The FileIOPermissionAttribute (shown earlier, in Listing 3) is applied to indicate declaratively that the code has the permission requested. In this example, the code checks that all callers in the stack have I/O permission.