Ответ 1
Наконец-то я получил его, я добавил
<trust level="Full" />
в system.web.
С средой AdoNetAppender перестает работать, но FileAppender все еще работает для средних и высоких.
Я могу писать в файл журнала с помощью сервера 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 не распознал его часть.
Наконец-то я получил его, я добавил
<trust level="Full" />
в system.web.
С средой AdoNetAppender перестает работать, но FileAppender все еще работает для средних и высоких.
Вы можете включить внутреннюю отладку 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.
Используйте инструмент, например Process Monitor, и загляните в процесс IIS. Я подозреваю, что он пытается создать файл журнала в каталоге, к которому у учетной записи IIS нет доступа.
Следуя этому тесту, укажите абсолютный путь к файлу журнала, который, как известно, имеет доступ к IIS-процессу.
Заходите ли вы в проводник Windows и проверяете правильных пользователей (NETWORK SERVICE?) имеют разрешения на запись?
У меня была такая же проблема. Я решил это, изменив конфигурацию IIS 7. Скорее просто...
Перейдите к дополнительным настройкам пула приложений и установите "Загрузить профиль пользователя" в true! Затем убедитесь, что IUSR (пользователь IIS) имеет разрешение на запись в путь к журналам.
Кроме того, как правило, я добавляю поддержку 32-битных приложений, это полезно при загрузке и использовании сборок от третьих сторон, где вы не знаете, были ли они выполнены для 32, 64 или независимых.
Я нашел это, прочитав эту статью: http://learn.iis.net/page.aspx/624/application-pool-identities/
С уважением, Tiago.
Попробуйте предоставить пользователю IIS AppPool\DefaultAppPool полное разрешение на каталог журнала. Это помогло мне хотя бы раз.