Re: issues with log4net 2.0.9 under IIS for projects using .net framework 4.5+
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 jmit...@berkeley.edu On Tue, Sep 8, 2020, 9:59 PM Davyd McColl 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" > 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" >> 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 depend
Re: issues with log4net 2.0.9 under IIS for projects using .net framework 4.5+
Thanks for the info! -d On September 9, 2020 07:29:28 "Joseph A. MITOLA" 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 jmit...@berkeley.edu On Tue, Sep 8, 2020, 9:59 PM Davyd McColl 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" 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" 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 depe
RE: issues with log4net 2.0.9 under IIS for projects using .net framework 4.5+
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" 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" 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" 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-50
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" 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" 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" 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
RE: issues with log4net 2.0.9 under IIS for projects using .net framework 4.5+
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 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" 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
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 [mailto:jmit...@berkeley.edu]
From: Davyd McColl [mailto:davyd.mcc...@codeo.co.za]
Sent: Tuesday, September 8, 2020 12:08 AM
To: jmit...@berkeley.edu [mailto:jmit...@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+
Have you tried an assembly rebind to force resolution to 2.0.9?
-d
On September 8, 2020 18:00:45 "Joseph A. MITOLA" 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
value="C:/logs/contentapps-proxy_%date{MMdd}.log" />
type="ContentAppsProxy.Filters.CustomAdoNetAppender">
value="System.Data.Entity.Infrastructure.SqlConnectionFactory,
EntityFramework" />
type="ContentAppsProxy.Filters.CustomSmtpAppender">
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
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
