You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by Davyd McColl <da...@codeo.co.za> on 2020/09/08 07:08:45 UTC

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

RE: issues with log4net 2.0.9 under IIS for projects using .net framework 4.5+

Posted by Davyd McColl <da...@codeo.co.za>.
Taking a step back, I'd also like you to check out:

https://github.com/fluffynuts/dotnet-utils

In particular, there are two utils in there which may help with determining what's going on, especially if the problem is something early like failure to resolve an assembly

In the bin folder, there are:
- toggle-fusion.cmd
- asmdeps.exe

If you're unsure about the latter, you're free to build your own from the source in that repo -- the binary is supplied for convenience only

Here's what they do:
toggle-fusion.cmd will toggle fusion logging on the host machine. Be aware that fusion logging will negatively impact performance _a lot_ but you'll end up with logs in C:\fusion-logs telling you about errors resolving assemblies

asmdeps.exe will give you information about assembly dependencies. By default, when it runs, it shows you a colored tree-view of assembly dependencies for the assemblies provided on the CLI. You can turn off color and add `-p` to get paths for the assemblies that are resolved (and would be loaded at runtime).

Both should help to track down a missing assembly -- whether that's missing because there is no {X}.dll or missing because assemblies further up the chain are expecting a different version or an assembly with a different public key.

-d

On 2020/09/08 18:52:09, Davyd McColl <da...@codeo.co.za> wrote:
Have you tried an assembly rebind to force resolution to 2.0.9?
-d
On September 8, 2020 18:00:45 "Joseph A. MITOLA" <jm...@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
jmitola@berkeley.edu [mailto:jmitola@berkeley.edu]
 
 
From: Davyd McColl [mailto:davyd.mccoll@codeo.co.za]
Sent: Tuesday, September 8, 2020 12:08 AM
To: jmitola@berkeley.edu [mailto:jmitola@berkeley.edu]
Cc: dev@logging.apache.org [mailto: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
 

Re: issues with log4net 2.0.9 under IIS for projects using .net framework 4.5+

Posted by Davyd McColl <da...@gmail.com>.
Thanks for the info!

-d


On September 9, 2020 07:29:28 "Joseph A. MITOLA" <jm...@berkeley.edu> wrote:

> Sure, I use Visual Studio 2019 Community edition as my IDE which has a
> publish tool to deploy console and web applications. I then push my
> deployment files to github and have a scheduled task on the web server that
> pulls down the latest commits from the github server.
>
> Joseph A. Mitola, Information Systems Analyst
> University of California, Berkeley
> IST - Architecture, Platforms & Integration
> 2195 Hearst Avenue, 250-29
> Berkeley, CA 94720-4876
> 510-508-4443
> jmitola@berkeley.edu
>
> On Tue, Sep 8, 2020, 9:59 PM Davyd McColl <da...@gmail.com> wrote:
>
>> 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" <jm...@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
>>> jmitola@berkeley.edu
>>>
>>>
>>>
>>>
>>>
>>> *From: *Davyd McColl <da...@gmail.com>
>>> *Sent: *Tuesday, September 8, 2020 1:18 PM
>>> *To: *Joseph A. MITOLA <jm...@berkeley.edu>
>>> *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" <jm...@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
>>> jmitola@berkeley.edu
>>>
>>>
>>>
>>>
>>>
>>> *From: *Davyd McColl <da...@codeo.co.za>
>>> *Sent: *Tuesday, September 8, 2020 11:15 AM
>>> *To: *Joseph A. MITOLA <jm...@berkeley.edu>
>>> *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" <jm...@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
>>> jmitola@berkeley.edu
>>>
>>>
>>>
>>>
>>>
>>> *From: *Davyd McColl <da...@codeo.co.za>
>>> *Sent: *Tuesday, September 8, 2020 9:52 AM
>>> *To: *Joseph A. MITOLA <jm...@berkeley.edu>
>>> *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" <jm...@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
>>> jmitola@berkeley.edu
>>>
>>>
>>>
>>>
>>>
>>> *From: *Davyd McColl <da...@codeo.co.za>
>>> *Sent: *Tuesday, September 8, 2020 12:08 AM
>>> *To: *jmitola@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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>

Re: issues with log4net 2.0.9 under IIS for projects using .net framework 4.5+

Posted by "Joseph A. MITOLA" <jm...@berkeley.edu>.
Sure, I use Visual Studio 2019 Community edition as my IDE which has a
publish tool to deploy console and web applications. I then push my
deployment files to github and have a scheduled task on the web server that
pulls down the latest commits from the github server.

Joseph A. Mitola, Information Systems Analyst
University of California, Berkeley
IST - Architecture, Platforms & Integration
2195 Hearst Avenue, 250-29
Berkeley, CA 94720-4876
510-508-4443
jmitola@berkeley.edu

On Tue, Sep 8, 2020, 9:59 PM Davyd McColl <da...@gmail.com> wrote:

> 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" <jm...@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
>> jmitola@berkeley.edu
>>
>>
>>
>>
>>
>> *From: *Davyd McColl <da...@gmail.com>
>> *Sent: *Tuesday, September 8, 2020 1:18 PM
>> *To: *Joseph A. MITOLA <jm...@berkeley.edu>
>> *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" <jm...@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
>> jmitola@berkeley.edu
>>
>>
>>
>>
>>
>> *From: *Davyd McColl <da...@codeo.co.za>
>> *Sent: *Tuesday, September 8, 2020 11:15 AM
>> *To: *Joseph A. MITOLA <jm...@berkeley.edu>
>> *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" <jm...@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
>> jmitola@berkeley.edu
>>
>>
>>
>>
>>
>> *From: *Davyd McColl <da...@codeo.co.za>
>> *Sent: *Tuesday, September 8, 2020 9:52 AM
>> *To: *Joseph A. MITOLA <jm...@berkeley.edu>
>> *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" <jm...@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
>> jmitola@berkeley.edu
>>
>>
>>
>>
>>
>> *From: *Davyd McColl <da...@codeo.co.za>
>> *Sent: *Tuesday, September 8, 2020 12:08 AM
>> *To: *jmitola@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
>>
>>
>>
>>
>>
>>
>>
>>
>>
>

RE: issues with log4net 2.0.9 under IIS for projects using .net framework 4.5+

Posted by Davyd McColl <da...@gmail.com>.
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" <jm...@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
> jmitola@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" <jm...@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
> jmitola@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" <jm...@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
> jmitola@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" <jm...@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
> jmitola@berkeley.edu
>
> From: Davyd McColl
> Sent: Tuesday, September 8, 2020 12:08 AM
> To: jmitola@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
>

RE: issues with log4net 2.0.9 under IIS for projects using .net framework 4.5+

Posted by Davyd McColl <da...@gmail.com>.
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" <jm...@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
> jmitola@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" <jm...@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
> jmitola@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" <jm...@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
> jmitola@berkeley.edu
>
> From: Davyd McColl
> Sent: Tuesday, September 8, 2020 12:08 AM
> To: jmitola@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
>

RE: issues with log4net 2.0.9 under IIS for projects using .net framework 4.5+

Posted by Davyd McColl <da...@codeo.co.za>.
Have you tried an assembly rebind to force resolution to 2.0.9?

-d


On September 8, 2020 18:00:45 "Joseph A. MITOLA" <jm...@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
> jmitola@berkeley.edu
>
> From: Davyd McColl
> Sent: Tuesday, September 8, 2020 12:08 AM
> To: jmitola@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
>