To be able to access the event log, your assembly must be granted the EventLogPermission by code access security policy. If it is not, for example, because it is running within the context of a medium trust Web application, you need to sandbox your event logging code. For more information about sandboxing access to the event log, see Chapter 9, "Using Code Access Security with ASP.NET."
If you want to constrain the actions of event log wrapper code perhaps code written by another developer or development organization you can use declarative attributes together with SecurityAction.PermitOnly as shown in the following example.
The following attribute ensures that the WriteToLog method and any methods it calls can only access the local computer's event log and cannot delete event logs or event sources. These operations are not permitted by EventLogPermissionAccess.Instrument .
[EventLogPermission(SecurityAction.PermitOnly, MachineName=".", PermissionAccess=EventLogPermissionAccess.Instrument)] public static void WriteToLog( string message )
To enforce read-only access to existing logs, use EventLogPermissionAccess.Browse .
To document the permission requirements of your code, and to ensure that your assembly cannot load if it is granted insufficient event log access by code access security policy, add an assembly level EventLogPermissionAttribute with SecurityAction.RequestMinimum as shown in the following example.
// This attribute indicates that your code requires the ability to access the // event logs on the local machine only (".") and needs instrumentation access // which means it can read or write to existing logs and create new event sources // and event logs [assembly: EventLogPermissionAttribute(SecurityAction.RequestMinimum, MachineName=".", PermissionAccess= EventLogPermissionAccess.Instrument)]