Почему Log4Net не создает файл журнала в производстве?
Даже при том, что D, наследовался C, D не может получить доступ к защищенным участникам C. D может получить доступ к защищенному D (и частный!) участники, поэтому при помещении другого экземпляра D там вместо C, все работало бы. Но поскольку Greg заявил, C мог действительно быть чем-то совершенно другим, и потому что компилятор не знает, каков C действительно, это должно препятствовать тому, чтобы D получил доступ к чему-то, к чему D не может на самом деле смочь получить доступ.
ряд А сообщений, объясняющих это с точки зрения компилятора C#:
8 ответов
I have found the problem. Permissions were CORRECT. Turns out that using a web deployment project also creates a precompliled.config file in the root. I had not copied that to the production enivornment. As soon as that was in the everything worked. Sorry no one got the bounty.
Имеет ли рабочий процесс достаточные привилегии для записи в каталог журнала? Полагаю, дело не в этом. Вы можете дать группе рабочих процессов права на запись в каталог и посмотреть, решит ли это вашу проблему.
This has happened to me before and was permissions on the ASPNET user to create the files where needed. Can check if there is anything in the windows event log indicating this?
To check for the kind of thing (we watch the watcher!) we output where the log4net was going to work by writing this out using the OutputDebugString() via pinvoke.. We also put this in a try catch to ensure that we discover errors regarding this as it's very important to use to be able to log correctly.
Проверьте права доступа к ожидаемому выходному каталогу и убедитесь, что веб-служба может писать в него. Самый простой способ сделать это - запустить filemon.exe (приложение SysInternals) и соответствующим образом ограничить его. Это должно сообщать вам, если что-то не получается, и вы можете исправить это при необходимости
Make sure log4net get's configured properly. Maybe the dll is alright but the config file is missing? log4net could be there but just does not have any active appenders.
, чтобы убедиться, что log4net настроен правильно, я создаю UDP Appender, который ведет журнал на порт 9090. Я использую бензопилу http://logging.apache.org/chainsaw/index. html , чтобы проверить записи журнала.
с его помощью вы можете проверить, что хотя бы некоторые записи в журнале выполнены и что регистратор работает.
UDP Appender Config
<appender name="UdpAppender" type="log4net.Appender.UdpAppender">
<remoteAddress value="localhost" />
<remotePort value="9090" />
<layout type="log4net.Layout.XmlLayoutSchemaLog4j">
<locationInfo value="true" />
</layout>
</appender>
Chainsaw XML
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/" debug="false">
<plugin name="LocalReceiver" class="org.apache.log4j.net.UDPReceiver">
<param name="Port" value="9090" />
</plugin>
</log4j:configuration>
Похоже, что корень вашей проблемы в том, что событие Application_Start в global.asax не запускается.
Существует "известная" проблема при развертывании из VS 2005 в Windows 2003, что Application_Start не срабатывает.
Содержимое Global.asax.cs будет скомпилировано в dll. Но Application_Start не запустится, если не указан файл Global.asax.
Вот пара соответствующих ссылок:
http://accidentaltechnologist.com/asp-net/application_start-not-firing- and-the-globalasax /
http://www.velocityreviews.com/forums/t300292-web-deployment-projects-globalasax-problem.html
Есть и другие возможности, которые описаны в приведенных выше ссылках.
Надеюсь, это поможет
Шираз
Добавьте это в файл AssemblyInfo.cs и проверьте
[assembly: log4net.Config.XmlConfigurator(Watch=true)]