Gibt es Bereiche gültiger Ereignis-IDs, die von benutzerdefinierten Anwendungen bei der Protokollierung in Windows EventLog verwendet werden sollten? Oder ich kann jede Event-ID meiner Wahl verwenden (1,2,3,4 ....). P.S, ich entwickle in C# .NET.Welche Ereignis-ID für meine benutzerdefinierten Ereignisprotokolleinträge?
EventIds sind anwendungsspezifisch, sodass Sie beliebige Bereiche verwenden können. Stellen Sie sicher, dass Sie dokumentieren, was Sie verwendet haben und wo Sie sicherstellen können, dass Sie keine ID zweimal verwenden oder das Debugging vereinfachen.
Aber bedenken ...
Wie damals, als Henry Ford sagte: „Sie irgendeine Farbe, die Sie wollen so lange haben, wie es schwarz ist“ - auch unabhängig von Bereich Sie wie solange dieser Bereich innerhalb verwenden fällt der Bereich von 0 und 65535.
Sicher genug, es liegt am Autor zu definieren und verfolgen Ereignis-IDs, die sie verwenden und was sie bedeuten.
Hier ist eine Referenz: http://msdn.microsoft.com/en-us/library/e29k5ebc.aspx - Besonders interessant ist der Teil über das Schreiben von Nachrichten mit IPv6-Adressen (wegen der % Zeichen) in das Ereignisprotokoll. Ich wette, dass Sie einen Parameter verwenden können, um das zu umgehen.
Edit1: Ich habe das getestet und es ist nicht wahr, dass eventID 32bits ist. Es sind nur 16 Bits.
eventId ist Int32, von -2.147.483.648 bis 2.147.483.647
EventLog.WriteEntry Methode (String, String, EventLogEntryType, Int32)
public static void WriteEntry(
string source,
string message,
EventLogEntryType type,
int eventID
)
Ja, akzeptiert ein int32 als Parameter, aber wenn Sie ein int eingeben, das nicht im Bereich von 0 ist und 65535 löst eine Ausnahme aus. –
Ja. Du hast recht.Ich habe es jetzt getestet und ich bin überrascht, dass MS behauptet, es ist 32 Bit ... – MrHIDEn
Leider vermeiden viele APIs unsigned Integer-Typen. Sie sind [nicht CLS-konform] (http://stackoverflow.com/questions/6325/why-are-unsigned-ints-not-clls-compliant). –
Technisch man alle Werte zwischen 1 verwenden - 65536 dafür.
Aber wenn Sie jemand sind, Tonnen ausführlichen Protokolls wie ich schreibt werden Sie es schwierig finden, eine Reihe von Einträgen in Beziehung zusammen dann würde ich vorschlagen, einen zufälligen eindeutigen Wert jedes Mal, wenn der Code mit dieser führt zu generieren Sie kann die Ereignisse identifizieren, auch die viel bessere Idee wäre, Ihre eigene Log & Quelle zu erstellen, diese zu verwenden, anstatt alles im Anwendungsprotokoll zu schreiben. wie
Random rnd = new Random();
EventId = rnd.Next(0, 65535);
Darf ich den Grund für die Abstimmung nach unten wissen? –
Wahrscheinlich weil der Zweck der eventId dazu dient, den _type von event_ eindeutig zu identifizieren. Alle Ereignisse desselben Typs sollten die gleiche ID haben. Dies ermöglicht beispielsweise, dass die automatische Überwachung bestimmte Aktionen ausführen kann, wenn bestimmte Ereignisse auftreten. Das Zuweisen einer zufälligen ID widersetzt sich diesem Zweck. – Pete
@Pete Das macht Sinn, wenn Sie sich im Anwendungsprotokoll anmelden, obwohl es nur ein Vorschlag war. –
Die hallo Bits der ID zum Testen, Debuggen und andere Flaggen für die Entwicklung verwendet vorbehalten. Die verwendbaren Bits sind:
0x0000 - 0xFFFF
Die oberen Bits sollten vermieden werden, aber alle Werte für die unteren Bits sind verfügbar, wenn Sie eine benutzerdefinierte Quelle erstellen. Wenn Sie ein System oder eine bereits vorhandene Quelle verwenden, werden Sie kollidieren und wahrscheinlich die falsche Nachricht erhalten. Nachrichten werden aus der DLL-Datei der registrierten Quellen-Nachricht genommen. Eine benutzerdefinierte Nachrichtendatei kann mithilfe des Nachrichtendateicompilers aus dem SDK erstellt werden.
wo 65535 ist "ushort.MaxValue" –