2009-05-07 3 views
1

У меня есть этот простой код, который записывает добавляет журнал в текстовый файл:Почему StreamWriter не работает в службе Windows?

public static void RecordToFile(string filename, Log log) 
    { 
      TextWriter textWriter = new StreamWriter(Constants.APP_PATH + 
       "\\" + filename, true); 
      textWriter.WriteLine(log.ToString()); 
      textWriter.Close(); 
    } 

Это отлично работает в Windows Forms приложение. Однако, используя трюк instsrv and srvany, я сделал это Службой Windows. Служба работает нормально, обращается к базе данных, выполняет запросы и все ... Кроме этого StreamWriter. Журнал просто не обновляется, как следует. Любые идеи почему?

+2

Как он не работает? Вызывает ли это исключение? Если да, то когда и какое исключение? –

+1

Почему вы используете instsrv и srvany, а не просто создаете проект Windows Service в C#? В любом актере, как и другие комментаторы, вы можете разрешить проблемы разрешения. –

ответ

6

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

Итак, проверьте диалог свойств для службы и проверьте вкладку «Вход в систему», чтобы узнать, на что он входит.

+0

Лучший способ узнать, что происходит, - это иметь в журнале службы любые исключения из журнала событий Windows. Это довольно легко сделать в .Net – NotMe

+0

Да, ну, кроме того, если у службы даже нет прав на это, я тоже видел, что это происходит. –

+1

Мне нравится использовать Process Monitor для отладки проблем с правами на файл. В прошлом мне было очень много времени с IIS или проблемами обслуживания. Он может контролировать все обращения к файлам по процессам, и он расскажет вам о любом неудачном доступе вместе с используемым путем. это был инструмент sysinternals, но теперь он находится на сайте Microsoft. Вы можете найти его здесь: http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx – JMarsch

2

Возможные причины:

  1. Constants.APP_PATH указывает на сетевой диск - службы не работают в той же среде, вошедшего в систему пользователя, поэтому путь не может быть действительным
  2. разрешений - в зависимости от того, какой пользователь работает в службе, у него может не быть доступа к тому же набору каталогов, что и приложение WinForms
1

Без дополнительной информации ничто не может помочь. Каким образом он точно не работает? Вы получаете исключение? Он просто терпит неудачу?

Просто несколько советов ...

1) Не следует использовать конкатенацию для создания пути к файлу. Вместо этого используйте System.IO.Path.Combine. Как это:

TextWriter textWriter = new StreamWriter(
    System.IO.Path.Combine(Constants.APP_PATH, filename), true); 

2) Приложите ваш писатель в using() блоке. Например:

using(TextWriter textWriter = new StreamWriter(
     System.IO.Path.Combine(Constants.APP_PATH, filename), true)) 
{ 
    textWriter.WriteLine(log.ToString()); 
} 

3) Убедитесь, что учетная запись, используемая службой, имеет доступ к созданию/перезаписи файлов в этом каталоге. Часто учетные записи службы, такие как LOCAL_SYSTEM или NETWORK_SERVICE, не будут иметь те же разрешения, что и учетные записи пользователей. Это может объяснить, почему он работает как пользователь, но не как услуга. Также может быть, что ваша константа APP_PATH указывает на то, что определенная пользователем, например сопоставление дисков с сетевым ресурсом. Дисплеи дисков не охватывают пользователей, поэтому это также может быть проблемой.

+0

спасибо за советы. Я все еще пытаюсь решить проблему – karlipoppins

0

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

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