Thanks! I'm surprised that you had the experience you had, because those environments are very similar to ours at work. May I ask what process you use to deploy? We use Octopus.

At least if I see the same odd behaviour, I have one more idea to check (:

-d


On September 9, 2020 00:02:32 "Joseph A. MITOLA" <jmit...@berkeley.edu> wrote:

OK, sure. No webforms. I am maintaining two web applications, one MVC 5 app and one Web API, both running on .Net framework 4.6 and both now successfully using log4net 2.0.9

Joseph A. Mitola, Information Systems Analyst
University of California, Berkeley
IST - Enterprise Applications
2195 Hearst Avenue, 250-29
Berkeley, CA 94720-4876
510-508-4443
jmit...@berkeley.edu

From: Davyd McColl
Sent: Tuesday, September 8, 2020 1:18 PM
To: Joseph A. MITOLA
Cc: dev@logging.apache.org
Subject: RE: issues with log4net 2.0.9 under IIS for projects using .net framework 4.5+

Joseph
Glad you could figure it out! Sounds like your app is webforms? If not, if appreciate as much info as you can divulge. I ask because I didn't write asmdeps on a whimsey - I'm genuinely interested in debugging strange situations, so the more info I have to help the next person, the better.
Thanks
-d
On September 8, 2020 20:32:25 "Joseph A. MITOLA" <jmit...@berkeley.edu> wrote:
Thanks Davyd,

I found the issue.

First, I had to uninstall the “Microsoft Monitoring Agent” on the windows server because for some reason when log4net was causing the IIS app pool to crash, it also crashed the monitoring agent which prevented any log4net internal debug logs to write to the log file.

Once the monitoring agent was uninstalled, re-launching the application generated a log4net internal debug file. I noticed the first line in the file was still referencing version 2.0.8 because it was loading it from the .Net framework temporary libraries located in: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files

I simply manually deleted the temporary files, re-started IIS and launched the application. This time everything worked and in the log4net internal debug file it was now referencing version 2.0.9.

Very strange that I had to run these steps in order to clear the previous version from the cache but at least it’s working now. Also, I checked “auto generate binding redirects” in visual studio which automatically generates these assembly references.

Thanks for all your help,
Joseph

Joseph A. Mitola, Information Systems Analyst
University of California, Berkeley
IST - Enterprise Applications
2195 Hearst Avenue, 250-29
Berkeley, CA 94720-4876
510-508-4443
jmit...@berkeley.edu

From: Davyd McColl
Sent: Tuesday, September 8, 2020 11:15 AM
To: Joseph A. MITOLA
Cc: dev@logging.apache.org
Subject: RE: issues with log4net 2.0.9 under IIS for projects using .net framework 4.5+

Joseph
Let's try figuring out the root cause. I was quite hasty with the rebind idea, though it may ultimately solve the problem, if my hunch is right. An assembly rebind is a bit of configuration added to the app.config or web.config of a .net application that can direct it, at runtime, to change its behavior slightly when attempting to load a dependant assembly:
https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/redirect-assembly-versions
For example, if you had some dependency A which was built against log4net 2.0.8 and you upgraded your web app to 2.0.9, at runtime, your web app would be happy, but that dependency wouldn't. We can force the hand of the assembly resolver to tell it, basically, "when someone asks for log4net 2.0.8, give them this assembly here (2.0.9)". If nothing too drastic has changed in the version increment, all will go well. This is how I tested 2.0.9 in my work project. We have an intermediate dependency which abstracts logging (so we can mock out the logger in testing, and have the freedom to use another logging framework). That dependency wants 2.0.8 (my PR to update is still in review) and my web app is updated to 2.0.9. So I use an assembly rebind to convince the runtime to simply provide the 2.0.9 assembly to to intermediate. asmdeps may show you what's going on here. Assuming you have an asp.net mvc app, point asmdeps at the primary assembly (eg Website.dll) and see the resolved dependency tree. Adding the -p flag will tell you exactly which files would be loaded. A missing or mismatched assembly would become evident. Since asmdeps relies on the inbuilt assembly resolution mechanisms, it will also be "fooled" by a rebind, so if a rebind fixes the issue, asmdeps should show no broken dependency.
-d
On September 8, 2020 19:31:45 "Joseph A. MITOLA" <jmit...@berkeley.edu> wrote:
I tried uninstalling and re-installing, no effect. I don’t know what you mean by rebind?

Joseph A. Mitola, Information Systems Analyst
University of California, Berkeley
IST - Enterprise Applications
2195 Hearst Avenue, 250-29
Berkeley, CA 94720-4876
510-508-4443
jmit...@berkeley.edu

From: Davyd McColl
Sent: Tuesday, September 8, 2020 9:52 AM
To: Joseph A. MITOLA
Cc: dev@logging.apache.org
Subject: RE: issues with log4net 2.0.9 under IIS for projects using .net framework 4.5+

Have you tried an assembly rebind to force resolution to 2.0.9?
-d
On September 8, 2020 18:00:45 "Joseph A. MITOLA" <jmit...@berkeley.edu> wrote:
Hi Davyd,

The weird thing is everything had been working fine with same configuration, framework version 4.6, etc. and all I did was update the nuget package for log4net from 2.0.8 to 2.0.9. After that IIS w3wp process along with perfmon.dll process on the deployment server crashed when the application was launched. No error logs were reported even when I set the internal debug to true, nothing. But then, if I revert the nuget package back to 2.0.8, everything is normal again including the logs with the internal debugging turned on. So, it makes me think that maybe the 2.0.9 version is missing a dependency library or something but I couldn't find anything online to that effect.

Here is my config, I'm using RollingFileAppender, AdoNetAppender, and SmtpAppender

<log4net>
<appender name="LogFileAppender" type="log4net.Appender.RollingFileAppender">
<file type="log4net.Util.PatternString" value="C:/logs/contentapps-proxy_%date{yyyyMMdd}.log" />
<lockingModel type="log4net.Appender.FileAppender+MinimalLock" />
<rollingStyle value="Date" />
<datePattern value="yyyyMMdd" />
<appendToFile value="true" />
<maxSizeRollBackups value="14" />
<maximumFileSize value="1024KB" />
<layout type="log4net.Layout.PatternLayout">
<param name="ConversionPattern" value="%-5p %date{yyyy-MM-dd hh:mm:ss tt} [%thread] %m%n" />
</layout>
<preserveLogFileNameExtension value="true" />
</appender>
<appender name="CustomAdoNetAppender" type="ContentAppsProxy.Filters.CustomAdoNetAppender">
<bufferSize value="1" />
<connectionType value="System.Data.Entity.Infrastructure.SqlConnectionFactory, EntityFramework" /> <commandText value="INSERT INTO Log4Net_Error ([Date],[Thread],[Level],[Logger],[Message],[Exception]) VALUES (@log_date, @thread, @log_level, @logger, @message, @exception)" />
<parameter>
<parameterName value="@log_date" />
<dbType value="DateTime" />
<layout type="log4net.Layout.RawTimeStampLayout" />
</parameter>
<parameter>
<parameterName value="@thread" />
<dbType value="String" />
<size value="255" />
<layout type="log4net.Layout.PatternLayout">
<conversionPattern value="%thread" />
</layout>
</parameter>
<parameter>
<parameterName value="@log_level" />
<dbType value="String" />
<size value="50" />
<layout type="log4net.Layout.PatternLayout">
<conversionPattern value="%level" />
</layout>
</parameter>
<parameter>
<parameterName value="@logger" />
<dbType value="String" />
<size value="255" />
<layout type="log4net.Layout.PatternLayout">
<conversionPattern value="%logger" />
</layout>
</parameter>
<parameter>
<parameterName value="@message" />
<dbType value="String" />
<size value="4000" />
<layout type="log4net.Layout.PatternLayout">
<conversionPattern value="%message" />
</layout>
</parameter>
<parameter>
<parameterName value="@exception" />
<dbType value="String" />
<size value="2000" />
<layout type="log4net.Layout.ExceptionLayout" />
</parameter>
</appender>
<appender name="CustomSmtpAppender" type="ContentAppsProxy.Filters.CustomSmtpAppender">
<bufferSize value="512" />
<lossy value="false" />
<evaluator type="log4net.Core.LevelEvaluator">
<threshold value="Error" />
</evaluator>
<layout type="log4net.Layout.PatternLayout">
<conversionPattern value="%message" />
</layout>
<priority value="High" />
</appender>

<root>
<level value="ALL" />
<appender-ref ref="LogFileAppender" />
<appender-ref ref="CustomAdoNetAppender" />
<appender-ref ref="CustomSmtpAppender" />
</root>
</log4net>

Joseph A. Mitola, Information Systems Analyst
University of California, Berkeley
IST - Enterprise Applications
2195 Hearst Avenue, 250-29
Berkeley, CA 94720-4876
510-508-4443
jmit...@berkeley.edu

From: Davyd McColl
Sent: Tuesday, September 8, 2020 12:08 AM
To: jmit...@berkeley.edu
Cc: dev@logging.apache.org
Subject: RE: issues with log4net 2.0.9 under IIS for projects using .net framework 4.5+

Hi Joseph

I've performed a (rather belated) upgrade to log4net 2.0.9 on a work project targeting net462 and, apart from having to perform some assembly rebinds to handle dependencies which expect log4net 2.0.8, it's working fine with an ado.net appender and a rolling log file appender, so I'd really like to know more about your environment & configuration.

-d

Reply via email to