2008-10-10 5 views
11

Где бы вы записывали файл журнала ошибок, скажем ErrorLog.txt, в Windows? Имейте в виду, что путь должен быть открыт для основных пользователей для разрешений на запись файлов.Где лучше всего записывать журнал ошибок в Windows?

Я знаю, что журнал событий - это возможное место для записи ошибок, но работает ли он на «пользовательские» разрешения?

EDIT: Я нацелен на Windows 2003, но задал вопрос таким образом, чтобы иметь «общее руководство», где можно записывать журналы ошибок.
Что касается EventLog, у меня были проблемы раньше в приложении ASP.NET, где я хотел войти в журнал событий Windows, но у меня были проблемы с безопасностью, вызывающие у меня страдание. (Я не помню проблем, которые у меня были, но помню, что они были.)

+0

Можете ли вы уточнить тип программы или типа ошибки, которые вы собираетесь регистрировать. Насколько важны ошибки в долгосрочной перспективе. (например, веб-сервер?) – 2008-10-10 14:36:39

+0

Было бы полезно узнать, какую технологию вы разрабатываете, и какую версию ОС, на которую вы нацеливаете, тоже. :) – 2008-10-10 14:46:23

ответ

14

Вы считали, что вместо этого вы регистрируете средство просмотра событий? Если вы хотите написать свой собственный журнал, я предлагаю каталог локальных приложений для пользователей. Создайте каталог продуктов там. В разных версиях Windows это отличается.

В Vista вы не можете помещать файлы, подобные этому, в файлы c: \ program. У вас будет много проблем с этим.

В .NET, вы можете найти эту папку с этим:

Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData) 

И журнал событий довольно проста в использовании слишком:

http://msdn.microsoft.com/en-us/library/system.diagnostics.eventlog.aspx

0

% TEMP% всегда хорошо подходит для журналов, которые я нахожу.

+0

Если журналы относительно неважны долгосрочные, я бы согласился, Temp - это правильная вещь. – 2008-10-10 14:37:19

-5

Поместите его в каталог приложения. Пользователям потребуется доступ к папке для запуска и выполнения приложения, и вы можете проверить доступ на запись при запуске приложения.

Журнал событий является болью для устранения неполадок, но вы все равно должны размещать там значительные ошибки.

EDIT - вы должны заглянуть в MS Application Blocks для ведения журнала, если используете .NET. Они действительно облегчают жизнь.

Jeez Карма-убийцы. В следующий раз я даже не предложу предложения, когда плакат создает неполную почту.

+0

Журналы приложений не должны размещаться в каталоге приложения. В защищенной среде у неадминистраторов не будет доступа на запись. – 2008-10-10 14:37:20

+0

Ввод файла журнала в каталог, в котором установлено приложение, является идеей * BAD * * BAD *. Я не могу повторить это достаточно сильно. Пользователь в Vista может запускать приложение, но они НЕ МОГУТ (и НЕ МОЖЕТЕ) писать в каталог приложения в% PROGRAMFILES% – Rob 2008-10-10 14:38:04

+0

Не вариант для программ под Vista и плохая идея в Генеральная. Vista не позволит программе создавать файлы в «Program Files», поэтому, если приложение установлено там, регистрация будет неудачной. – workmad3 2008-10-10 14:38:37

3

Лично я предложил бы использовать журнал событий Windows, это здорово. Если вы не можете, напишите файл в каталоге ApplicationData или в каталоге ProgramData (Application Data for all users in Windows XP).

2

Стандартное расположение (ы):

C:\Documents and Settings\All Users\Application Data\MyApp 

или

C:\Documents and Settings\%Username%\Application Data\MyApp 

(ака %UserProfile%\Application Data\MyApp), который будет соответствовать вашему уровню пользователя требования разрешения. Он также разделяет журналы, созданные разными пользователями.

Использование .NET выполнения, они могут быть построены как:

AppDir= 
    System.Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData) 

или

AppDir= 
    System.Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData) 

следуют:

MyAppDir = IO.Path.Combine(AppDir,'MyApp') 

(Который, надеюсь, карты Виста профили тоже).

2

Журнал событий Windows определенно подходит для регистрации ошибок. Вы не ограничены журналом «Приложение», так как можно создать новую целевую запись журнала (например, «Мое приложение»). Возможно, это необходимо сделать как часть установки, поскольку я не уверен, что для этого требуются административные привилегии или нет. В C# есть пример Microsoft: http://support.microsoft.com/kb/307024.

В Windows 2008 также есть Event Log Forwarding, что может быть весьма полезно при использовании серверных приложений.

0

Против зерна здесь - это зависит от того, что вам нужно делать. Иногда вам нужно манипулировать результатами, поэтому log.txt - это путь. Он прост, изменен и прост в поиске.

Возьмите пример от Джоэла. Fogbugz отправит журнал/дамп сообщений об ошибках через http на свой сервер. Вы можете сделать то же самое и не беспокоиться о правах доступа пользователя на своем диске.

5

Текстовые файлы отлично подходят для серверного приложения (вы сказали, что Windows 2003). У вас должен быть отдельный файл журнала для каждого серверного приложения, расположение действительно согласуется с администраторами. Например. для приложений ASP.NET я часто видел, как они помещались на отдельный диск из приложения в структуре папок, которая имитирует структуру виртуального каталога.

Для клиентских приложений одним недостатком текстовых файлов является то, что пользователь может запускать несколько копий вашего приложения (если только вы не предприняли определенные шаги для предотвращения этого). Таким образом, у вас есть проблема конкуренции, если несколько экземпляров пытаются записать в один и тот же файл журнала. По этой причине я всегда предпочитаю журнал событий Windows для клиентских приложений. Одно из предостережений заключается в том, что вам необходимо быть администратором для создания журнала событий - это можно сделать, например. по установочному пакету.

Если вы используете файл, я бы предложил использовать папку Environment.SpecialFolder. Local ApplicationData, а не SpecialFolder.ApplicationData, как это было предложено другими. LocalApplicationData находится на локальном диске: вы не хотите, чтобы сетевые проблемы мешали вам регистрироваться, когда пользователь имеет перемещаемый профиль. Для приложения WinForms используйте Application.LocalUserAppDataPath.

В любом случае, я бы использовал файл конфигурации, чтобы решить, где регистрироваться, чтобы вы могли легко изменить его. Например. если вы используете Log4Net или подобную структуру, вы можете легко настроить, следует ли регистрироваться в текстовом файле, журнале событий, как в другом, так и в другом месте (например, в базе данных), без изменения вашего приложения.

1

Я согласен с Lou на этом, но я предпочитаю установить это в файле конфигурации, например, Джо. Вы можете использовать

значение файла = «$ {} APPDATA /Test/log-file.txt»

(«Test» может быть все, что вы хотите, или полностью удалены) в конфигурационном файле, который приводит к тому, файл журнала, который должен быть записан в «/ Documents and Settings/LoginUser/Application « Данные/тест »в Windows XP и«/Users/LoginUser/AppData/Роуминг/Тест в Windows Vista.

Я просто добавив это, как я только что потратил слишком много времени, выясняя, как сделать эту работу на Windows Vista ...

Это работает как есть с приложениями Windows. Для того, чтобы использовать регистрацию в веб-приложениях, я нашел запись в блоге Phil Хаек на это большой ресурс: http://haacked.com/archive/2005/03/07/ConfiguringLog4NetForWebApplications.aspx

0

мне лично не нравится использовать журнал событий Windows, где я сейчас нахожусь, потому что мы не имеем доступа на серверы производства, так что это означало бы, что нам нужно будет запрашивать доступ каждый раз, когда мы хотим посмотреть на ошибки. К сожалению, это не быстрый процесс, поэтому устранение неполадок полностью вызвано ожиданием кого-то другого. Мне также не нравится, что они теряются в других приложениях. Конечно, вы можете сортировать, но это всего лишь немного прокрутки нуклонов. Вы будете использовать комбинацию личных предпочтений вместе с ограничениями среды, в которой вы работаете. (Файл журнала, журнал событий или база данных)

Смежные вопросы