net - write error in event viewer c#

¿Cuáles son las mejores prácticas para la gestión de identificación de eventos?

Question

Estoy tratando de averiguar cómo administrar mis identificadores de eventos. Hasta este punto, he estado poniendo cada ID de evento en cada método manualmente con cada paso en un método numerado secuencialmente. Esto no me permite filtrar eventos de manera efectiva en el registro de eventos. Para utilizar el filtro en el registro de eventos, parece que cada evento registrado debe tener su propia identificación única.

Podría guardarlos todos en una tabla con la descripción vinculada a ellos, pero luego, cuando mi código se ejecuta, estoy registrando códigos de eventos "mágicos" sin sentido.

Hice una búsqueda en Google, pero parece que no sé cuáles son las palabras clave correctas que debo utilizar para llegar al fondo de este problema.

Gracias por adelantado

Answer 1

Al igual que la sugerencia de Ben, probablemente vale la pena usar un nivel de direccionamiento indirecto, pero en lugar de usar un int para el código, usaría una enumeración real, así que para el ejemplo de Ben:

public enum EventId
{
[Format("Building command object from {0}.")]
BuildingCommandObject = 1,
[Format("Command object build successfully.")]
CommandObjectBuilt = 2,
[Format("Connecting to {0}.")]
ConnectingToDatabase = 3,
[Format("Executing command against database {0}.")]
ExecutingCommand = 4,
[Format("Command executed successfully.")]
CommandExecuted = 5,
[Format("Disconnecting from {0}.")]
DisconnectingFromDatabase = 6,
[Format("Connection terminated")]
Disconnected = 7
}

O alternativamente (y de una manera más orientada a objetos) use el patrón de "enumeración inteligente":

public class LogEvent
{
public static readonly LogEvent BuildingCommandObject = new LogEvent(1,
"Building command object from {0}");
// etc
private readonly int id;
private readonly string format;
// Add the description if you want
private LogEvent(int id, string format)
{
this.id = id;
this.format = format;
}
public void Log(params object[] data)
{
string message = string.Format(format, data);
// Do the logging here
}
}

A continuación, puede llamar a:

LogEvent.BuildingCommandObject.Log("stuff");

Con un poco de trabajo puede exponer esto de manera segura con diferentes eventos de registro que tienen una interfaz diferente para hacerlo seguro (en tiempo de compilación) en términos de cuántos parámetros tiene cada uno. De hecho, estoy seguro de que podrías hacerlo usando interfaces y una clase anidada privada, pero son las 4 de la mañana y estoy demasiado cansado para escribirlo en la cajera de la cadena :)

Answer 2

Primero lo pensé, y aún no lo he pensado del todo, pero parece una posibilidad razonable:

public class LogEvent
{
/* This is the event code you reference from your code
* so you''re not working with magic numbers. It will work
* much like an enum */
public string Code;
/* This is the event id that''s published to the event log
* to allow simple filtering for specific events */
public int Id;
/* This is a predefined string format that allows insertion
* of variables so you can have a descriptive text template. */
public string DisplayFormat;
/* A constructor to allow you to add items to a collection in
* a single line of code */
public LogEvent(int id, string code, string displayFormat)
{
Code = code;
Id = id;
DisplayFormat = displayFormat;
}
public LogEvent(int id, string code)
: this(id, code, null)
{
}
public LogEvent()
{
}
}

Luego puede tener una clase de administrador de eventos que envuelve su lista de eventos proporcionando un método que consulta la lista de acuerdo con el parámetro que pasa, por ejemplo:

public class EventManager
{
private List<LogEvent> _eventList;
public LogEvent this[string eventCode]
{
get
{
return _eventList.Where(i => i.Code.Equals(eventCode)).SingleOrDefault();
}
}
public LogEvent this[int id]
{
get
{
return _eventList.Where(i => i.Id.Equals(id)).SingleOrDefault();
}
}
public void AddRange(params LogEvent[] logEvents)
{
Array.ForEach(logEvents, AddEvent);
}
public void Add(int id, string code)
{
AddEvent(new LogEvent(id, code));
}
public void Add(int id, string code, string displayFormat)
{
AddEvent(new LogEvent(id, code, displayFormat));
}
public void Add(LogEvent logEvent)
{
_events.Add(logEvent);
}
public void Remove(int id)
{
_eventList.Remove(_eventList.Where(i => i.id.Equals(id)).SingleOrDefault());
}
public void Remove(string code)
{
_eventList.Remove(_eventList.Where(i => i.Code.Equals(code)).SingleOrDefault());
}
public void Remove(LogEvent logEvent)
{
_eventList.Remove(logEvent);
}
}

Esto permite una gestión simplificada de las definiciones de eventos que se pueden administrar de forma independiente para cada TraceSource.

var Events = new EventManager();
Events.AddRange(
new LogEvent(1, "BuildingCommandObject", "Building command object from {0}."),
new LogEvent(2, "CommandObjectBuilt", "Command object built successfully."),
new LogEvent(3, "ConnectingToDatabase", "Connecting to {0}."),
new LogEvent(4, "ExecutingCommand", "Executing command against database {0}".),
new LogEvent(5, "CommandExecuted", "Command executed succesfully."),
new LogEvent(6, "DisconnectingFromDatabase", "Disconnecting from {0}."),
new LogEvent(7, "Disconnected", "Connection terminated.")
)

Y puede acceder a los eventos utilizando el identificador significativo que asignó:

var evt = Events["ConnectingToDatabase"];
TraceSource.TraceEvent(TraceEventType.Information, evt.Id, evt.DisplayFormat, otherParams);

o

var evt = Events[1024];
Console.WriteLine("Id: {1}{0}Code: {2}{0}DisplayFormat{3}",
Environment.NewLine, evt.Id, evt.Code, evt.DisplayFormat);

Esto probablemente simplificaría la administración de eventos, ya no llamará a sus eventos con números mágicos, es fácil de administrar todos sus eventos en un solo lugar: su clase EventManager y aún puede filtrar su registro de eventos por los números mágicos que requiere. filtrado por.

Answer 3

Sé que esta es una pregunta antigua, pero tal vez buscaba una manera de hacer algo como esto, en el que usa identificadores de eventos personalizados para diferentes propósitos, y llámelos a los lugares apropiados en su código:

public class ErrorLog
{
//Notifications
public const int NOTIFY_ALPHA = 2000;
public const int NOTIFY_BETA = 2001;
public const int NOTIFY_GAMMA = 2002;
public static string[] errMessage =
{"Critical Error.", //2000
"File not found.", //2001
"Unknown Event Action Encountered - " //2002
};
public static string GetErrMsg(int errNum)
{
return (errMessage[errNum-2000]);
}
private static bool ErrorRoutine(int eventLogId)
{
try
{
string eventAppName = "My Application";
string eventLogName = "My Apps Events";
string msgStr = GetErrMsg(eventLogId); // gets the message associated with the ID from the constant you passed in
if (!EventLog.SourceExists(eventAppName))
EventLog.CreateEventSource(eventAppName, eventLogName);
EventLog.WriteEntry(eventAppName, msgStr, EventLogEntryType.Error, eventLogId);
return true;
}
catch (Exception)
{
return false;
}
}
}

Y luego llamaría a esta clase así, cuando lanzó su excepción:

ErrorLog.ErrorRoutine(ErrorLog.NOTIFY_ALPHA);

En lo que respecta a las mejores prácticas, diría que es bueno tener todo el manejo de errores en su propia clase si es tan personalizado (o más, como cuando se incluyen las advertencias y la información en EventLogEntryTypes o información adicional que la que ofrecen los mensajes enlatados). ) que este. Al tener identificadores individuales, puede consultar sus mensajes de esta manera, lo que le facilitará la vida cuando intente saber qué mensaje llamar, cuándo y dónde.