Log4net - Агенты не работают в IIS7.5

Я могу писать в файл журнала с помощью сервера log4net и Cassini/IIS dev, но когда я использую IIS7.5, я не могу записать файл.

Первоначально я получил исключение безопасности, поэтому добавил requirePermission="false", и исключение удалилось, но файл не был создан.

Уровень доверия заполнен в соответствии с IISM.

Я не могу заставить это работать на моей собственной машине, мне интересно, что произойдет, когда я перейду на ISP (discountASP).

Здесь настройка log4net:

<configSections>
    <section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" requirePermission="false"  />
</configSections>

<log4net>
    <appender name="FileAppender" type="log4net.Appender.FileAppender">
        <file value="log-file.txt" />
        <appendToFile value="true" />
        <encoding value="utf-8" />
        <layout type="log4net.Layout.SimpleLayout" />
    </appender>
    <root>
        <level value="DEBUG" />
        <appender-ref ref="FileAppender" />
    </root>
</log4net>

С#

log4net.Config.XmlConfigurator.Configure();
ILog Log = log4net.LogManager.GetLogger(System.Reflection.MethodBase.GetCurrentMethod().DeclaringType);
Log.Info("This is a test");

Любые подсказки?

ASP.NET 3.5, VS2008, Windows 7, IIS7.5, log4net 1.2.10

EDIT:

Я использовал тестовое веб-приложение, которое запускалось в Cassini и запускало его в IIS7.5, и оно работало так, чтобы в моем веб-приложении было что-то конкретное, что предотвращает запуск log4net. Там в ELMAH, кэширование вывода, AJAX Control Toolkit, проверка подлинности форм, ssl, переписывание URL и т.д. Помимо добавления каждого из них в тестовое приложение, есть лучший способ выяснить, что вызывает log4net работать?

UPDATE:

Я использовал AdoNetAppender, чтобы держаться подальше от проблем с разрешением файла, и я все равно получаю тот же результат. AdoNetAppender работает для тестового приложения, работающего на Cassini и IIS, но он не работает в моем веб-приложении. Получение следующего исключения:

System.Security.SecurityException: запрос на разрешение типа "System.Configuration.ConfigurationPermission, System.Configuration..." не выполнен.

ОБНОВЛЕНИЕ 2: Я ошибался, что тестовый файл webapp fileAppender работал в IIS7.5. Вот что происходит: тестовый файл webappAppender и AdoDotNetAppender работают в Cassini/IIS dev, но не в IIS7.5. Поэтому я считаю, что это проблема IIS, а не мой webapp.

Примечание. Я запускаю VS2008 в качестве администратора, но вошел в Windows 7 как nonAdmin. Кроме того, я запускаю Windows 7 Home Premium, а не Professional.

Я предоставил NETWORK SERVICE полное разрешение на использование корневого каталога в сети и все еще не создал файл. Также предоставил ВСЕЕ полное разрешение, без файла.

Так как adoDotNetAppender тоже не работал (но это было в dev IIS), я думаю, что в дополнение к разрешениям файла может возникнуть другая проблема.

ОБНОВЛЕНИЕ 3:

Я получил его для работы с FileAppender на IIS7. Если я добавлю это:

<identity impersonate="true"
    userName="zzz"
    password="yyy" />

и если пользователь является администратором, он работает. Если это я, а не админ, это не так. Так что это вопрос с разрешениями. Но я предоставил права EVERYONE каталогу, в который файл был написан до и не работал, поэтому есть разрешение в другом месте. Кроме того, хотя FileAppender теперь работает с олицетворением, AdoNetAppender stil не работает в IIS7. Я попытался добавить:

<securityContext type="log4net.Util.WindowsSecurityContext">
    <userName value="zzz" />
    <password value="yyy" />
    <domain value="aaa" />
</securityContext>

в раздел AdoNetAppender, но все равно сбой.

Я добавил щедрость для тех, кто может помочь мне получить AdoNetAppender, работающий с IIS7.5.

ОБНОВЛЕНИЕ 4:

Наконец-то я ухватился за трассировку стека. Вот он:

log4net:ERROR [AdoNetAppender] Failed in DoAppend
System.Security.SecurityException: Request for the permission of type 'System.Security.Permissions.SecurityPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.
       at log4net.Util.LogicalThreadContextProperties.GetProperties(Boolean create)
       at log4net.Core.LoggingEvent.CreateCompositeProperties()
       at log4net.Core.LoggingEvent.CacheProperties()
       at log4net.Core.LoggingEvent.FixVolatileData(FixFlags flags)
       at log4net.Core.LoggingEvent.set_Fix(FixFlags value)
       at log4net.Appender.BufferingAppenderSkeleton.Append(LoggingEvent loggingEvent)
       at log4net.Appender.AppenderSkeleton.DoAppend(LoggingEvent loggingEvent)
The action that failed was:
LinkDemand
The type of the first permission that failed was:
System.Security.Permissions.SecurityPermission
The Zone of the assembly that failed was:
MyComputer

У меня был SQL Profiler и ничего не делалось с SQL Server. Кроме того, учетная запись SQL Server имеет правильные привилегии для вставки. Кроме того, я удалил раздел SecurityContext, поскольку log4net не распознал его часть.

Ответы

Ответ 1

Наконец-то я получил его, я добавил

<trust level="Full" />

в system.web.

С средой AdoNetAppender перестает работать, но FileAppender все еще работает для средних и высоких.

Ответ 2

Вы можете включить внутреннюю отладку log4net, добавив ключ log4net.Internal.Debug в файл конфигурации приложения.

<appSettings>
    <add key="log4net.Internal.Debug" value="true"/>
</appSettings>

Это будет писать отладочные сообщения на консоль и System.Diagnostics.Trace. Затем вы можете зарегистрировать эти сообщения в текстовом файле, добавив в свой конфигурационный файл прослушиватель трассировки. Убедитесь, что приложение имеет разрешение на запись в файл.

<system.diagnostics>
    <trace autoflush="true">
        <listeners>
            <add 
                name="textWriterTraceListener" 
                type="System.Diagnostics.TextWriterTraceListener" 
                initializeData="C:\tmp\log4net.txt" />
        </listeners>
    </trace>
</system.diagnostics>

В качестве альтернативы сообщения трассировки также записываются в системный отладчик, поэтому для захвата сообщений вы можете использовать утилиту, например DebugView. Подробнее см. log4Net FAQ.

Ответ 3

Используйте инструмент, например Process Monitor, и загляните в процесс IIS. Я подозреваю, что он пытается создать файл журнала в каталоге, к которому у учетной записи IIS нет доступа.

Следуя этому тесту, укажите абсолютный путь к файлу журнала, который, как известно, имеет доступ к IIS-процессу.

Ответ 4

Заходите ли вы в проводник Windows и проверяете правильных пользователей (NETWORK SERVICE?) имеют разрешения на запись?

Ответ 5

У меня была такая же проблема. Я решил это, изменив конфигурацию IIS 7. Скорее просто...

Перейдите к дополнительным настройкам пула приложений и установите "Загрузить профиль пользователя" в true! Затем убедитесь, что IUSR (пользователь IIS) имеет разрешение на запись в путь к журналам.

Кроме того, как правило, я добавляю поддержку 32-битных приложений, это полезно при загрузке и использовании сборок от третьих сторон, где вы не знаете, были ли они выполнены для 32, 64 или независимых.

Я нашел это, прочитав эту статью: http://learn.iis.net/page.aspx/624/application-pool-identities/

С уважением, Tiago.

Ответ 6

Попробуйте предоставить пользователю IIS AppPool\DefaultAppPool полное разрешение на каталог журнала. Это помогло мне хотя бы раз.