Этому блог здесь: The EventSource NuGet package and support for the Windows Event Log (Channel Support) имеет связь с редким EventSource User's Guide документа, который гласит следующее:
ли использовать Имя свойство EventSourceAttribute, чтобы обеспечить a описательное, квалифицированное имя для поставщика событий ETW, представленное вашим источником событий. По умолчанию используется короткое имя источника вашего события , что может привести к столкновениям, поскольку имена поставщиков ETW разделяют на одно пространство имен в машинном пространстве. Пример хорошего имени поставщика «<CompanyName>-<Product>-<Component>
». После этого 3-элементного соглашения приложение Event Viewer отобразит ваши журналы событий в иерархии логических папок : “Application and Services Logs/<CompanyName>/<Product>/<Component>
".
Который имеет тенденцию указывать, что тире являются скорее соглашением, чем строгим требованием (поэтому я считаю, что вы можете разобрать его самостоятельно). Обратите внимание, что блог по-прежнему открыт для комментариев.
Что касается имен, которые не совпадают, то есть недокументированная функция EvtIntGetClassicLogDisplayName, которая может получить имя, отображаемое в средстве просмотра событий. Вот как использовать его с сеансом и имя журнала:
static void Main(string[] args)
{
var session = new EventLogSession();
foreach (string name in session.GetLogNames())
{
Console.WriteLine(GetDisplayName(session, name));
}
}
А вот код поддержки (так как он документирован, использовать на свой страх и риск, плюс это, кажется, полезно в основном для этого «OAlert» поэтому я не уверен, что это того стоит):
public static string GetDisplayName(EventLogSession session, string logName)
{
var sb = new StringBuilder(512);
int bufferUsed = 0;
if (EvtIntGetClassicLogDisplayName(GetSessionHandle(session).DangerousGetHandle(), logName, 0, 0, sb.Capacity, sb, out bufferUsed))
return sb.ToString();
return logName;
}
private static SafeHandle GetSessionHandle(EventLogSession session)
{
return (SafeHandle)session.GetType().GetProperty("Handle", BindingFlags.Instance | BindingFlags.NonPublic).GetValue(session);
}
[DllImport("wevtapi.dll", CharSet = CharSet.Unicode)]
private static extern bool EvtIntGetClassicLogDisplayName(IntPtr session, [MarshalAs(UnmanagedType.LPWStr)] string logName, int locale, int flags, int bufferSize, [MarshalAs(UnmanagedType.LPWStr)] StringBuilder displayName, out int bufferUsed);
Спасибо, Саймон. Какой отличный ответ. GetDisplayName работает как шарм (хотя страшно использовать DangerousGetHandle - мне интересно, проведет ли это обзор кода :). Однако соглашение об именах, похоже, не прилипает должным образом. Даже в приведенном выше скриншоте, который я добавил, Microsoft-SQLServerDataTools не помещается под Microsoft. Кроме того, когда я вызываю GetLogNames(), я вижу конфигурацию Microsoft-IIS, которая не отображается в Microsoft на скриншоте выше. Я думаю, что может быть другой «скрытый» API, как тот, который вы обнаружили. – Mark
Аналогичным примером может служить журнал Microsoft-Rdms-UI. – Mark
Microsoft-SQLServerDataTools просто не соответствует 3-элементному соглашению (только 2 части, какой-то парень в MS не читал документ ...). Кроме того, многие вещи появятся, если вы проверите меню EventViewer View/Show Analytic и Debug Logs. Эти журналы отмечены «Diagnostic» или «Analytic». Что касается Microsoft-IIS-Configuration, это журнал, который связан с провайдером «Microsoft-Windows-IIS-Configuration» (вы можете обнаружить эту ссылку, используя «new ProviderMetadata» («Microsoft-Windows-IIS-Configuration», session, null) .LogLinks'). Пространства имен между журналами и их провайдером не всегда согласованы ... –