wcf пытается настроить трассировку для отладки, не записывая в файл журнала - PullRequest
11 голосов
/ 17 мая 2010

вот мой web.config, запускающий службу WCF в приложении на IIS7, но в указанный файл ничего не записывается. разрешение на файл было предоставлено для всех.

<system.diagnostics>
  <sources>
   <source name="System.ServiceModel" switchValue="Information, ActivityTracing,     error, warning, critical" propagateActivity="true">
    <listeners>
     <add name="traceListener"
  type="System.Diagnostics.TextWriterTraceListener"
  initializeData="c:\log\tracestext.log" />

    </listeners>
  </source>
  </sources>
 </system.diagnostics>

Я могу просто добавить ссылку на сервис.
Затем я пытаюсь вызвать службу из приложения Windows и через несколько минут на компьютере с приложением Windows появляется сообщение об ошибке: «Клиент не может завершить согласование безопасности в течение настроенного времени ожидания (00:00:00). текущий этап переговоров равен 1 (00:00:00). "

но абсолютно ничего не записывается в файл журнала трассировки, указанный в конфиге.

Есть ли что-то еще, что мне нужно сделать, чтобы включить трассировку? спасибо за вашу помощь

РЕДАКТИРОВАТЬ: раздел «Источники» теперь соответствует разделу, рекомендованному здесь: http://msdn.microsoft.com/en-us/library/aa702726.aspx

Я добавил раздел «диагностика. Ведение журнала сообщений» в «system.servicemodel»

и средство просмотра событий показывает: «Ведение журнала сообщений включено. Чувствительная информация может регистрироваться в незашифрованном виде, даже если она была зашифрована в сети: например, тела сообщений. Имя процесса: w3wp Идентификатор процесса: 1784 «

но файл журнала все еще пуст

Ответы [ 4 ]

15 голосов
/ 17 мая 2010

Да - вы только что определили некоторый источник трассировки .NET и слушателей - но вы еще не проинструктировали WCF о том, чтобы фактически выполнить трассировку!

Вам также необходимо:

<system.serviceModel>
    <diagnostics>
        <messageLogging 
            logMessagesAtTransportLevel="true" logMessagesAtServiceLevel="false"
            logMalformedMessages="true" logEntireMessage="true"
            maxSizeOfMessageToLog="65535000" maxMessagesToLog="500" />
    </diagnostics>
</system.serviceModel>

Эти две секции конфигурации должны объединить!

Чтобы ваши сообщения сразу же записывались обратно в файл журнала, вы можете добавить параметр в раздел <system.diagnostics>:

<system.diagnostics>
    ... everything you already have....

    <trace autoflush="true" />
</system.diagnostics>
4 голосов
/ 17 апреля 2011

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

Идентификатор можно найти в консоли управления IIS 7. Выберите пул приложений, который использует ваше веб-приложение. Нажмите на Дополнительные настройки ... В окне свойств найдите поле идентификатора. Это может сказать Сетевой сервис. Это учетная запись, для которой требуется разрешение на запись в папку вывода журнала.

Если у вас уже есть файл журнала в этом каталоге, попробуйте удалить его и позволить инфраструктуре создать его.

Надеюсь, это поможет.

0 голосов
/ 10 февраля 2017

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

  • Щелкните правой кнопкой мыши в каталоге журнала
  • Нажмите на вкладку «Безопасность»
  • Нажмите изменить
  • В разделе «Имена групп или пользователи» выберите «Users MachineName \ Users»
  • В разделе «Разрешения» выдается разрешение на запись

У меня все работало нормально.

0 голосов
/ 09 августа 2012
  1. Убедитесь, что вы настроили как system.diagnostics, так и System.serviceModel / разделы диагностики настроены.

  2. Убедитесь, что они настроены в правильном файле App.config / Web.config. Стоит отметить, что несколько Конфигурационные файлы могут существовать в проекте, и тот, который используется, зависит от Конфигурация сборки.

Лично у меня был тот же симптом, пока я не заметил, что я поместил разделы в app.config (в моем случае, трассировка на стороне клиента) вместо app.DebugLocal.config . Последний использовался, поскольку моя конфигурация сборки была установлена ​​на DebugLocal .

...