Log4net
  1. Log4net
  2. LOG4NET-174

log4net.dll references assemblies that are not part of the .NET 3.5 SP1 client profile

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Duplicate
    • Affects Version/s: 1.2.10
    • Fix Version/s: None
    • Component/s: Builds
    • Labels:
      None
    • Environment:
      .Net 3.5 SP1

      Description

      .Net 3.5 SP1 / VS 2008 SP1 has a new build feature: the "client-only framework subset" switch in the projects settings, meaning that the developer can specify that only a limited subset of the .Net framework is used. This helps in reducing the size of installers that include the .Net framework.

      Unfortunately, log4net.dll (1.2.10) has references to System.Web, which is not part of this "client-only framework subset". This leads to the following compilation warning:
      <<<
      C:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets : warning MSB3253: The referenced assembly "log4net, Version=1.2.10.0, Culture=neutral, PublicKeyToken=1b44e1d426115821, processorArchitecture=MSIL" has a dependency on "System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" which is not listed as part of the "Client" TargetFrameworkSubset. If this dependent reference is required, you may get compilation errors.
      >>>

      My proposal is to split log4net.dll into a new log4net.dll (core+generic appenders) and into a separate appender DLL (log4net.server.dll) for deployment on servers only.

        Issue Links

          Activity

          Hide
          Robert A. McCarter added a comment -

          I second this - a logger should not require a reference to System.Web.
          Requiring a client (console, WinForms or WPF) application to have a reference to System.Web isn't cool.

          Show
          Robert A. McCarter added a comment - I second this - a logger should not require a reference to System.Web. Requiring a client (console, WinForms or WPF) application to have a reference to System.Web isn't cool.
          Hide
          Patrick Earl added a comment -

          This is of greater concern now with VS2010. While VS2008 used to just issue warnings about the assemblies, VS2010 considers the problem to be an error and won't even compile, even when targetting the same framework version as before.

          As well, as far as I understand, Microsoft will only be releasing the .NET 4 Client Profile (rather than the full framework) through automatic Windows updates. This means that people wishing to deploy to a wide audience without probitively large downloads would have difficulty utilizing log4net, and important packages that depend on it, such as NHibernate.

          All I can see that would need to be done is move the Asp* files to a second assembly, such as suggested above, and provide a mechanism to have the server pattern converters register themselves as is done in these lines:

          s_globalRulesRegistry.Add("aspnet-cache", typeof(AspNetCachePatternConverter));
          s_globalRulesRegistry.Add("aspnet-context", typeof(AspNetContextPatternConverter));
          s_globalRulesRegistry.Add("aspnet-request", typeof(AspNetRequestPatternConverter));
          s_globalRulesRegistry.Add("aspnet-session", typeof(AspNetSessionPatternConverter));

          It would be a breaking change for the next release, since people would need to reference the second assembly and potentially have a different line of initialization code when web classes are needed.

          Microsoft has shown that the client profile is very much a first class citizen at this point (even automatically targetting new projects towards it), and it should be supported as such by log4net.

          Show
          Patrick Earl added a comment - This is of greater concern now with VS2010. While VS2008 used to just issue warnings about the assemblies, VS2010 considers the problem to be an error and won't even compile, even when targetting the same framework version as before. As well, as far as I understand, Microsoft will only be releasing the .NET 4 Client Profile (rather than the full framework) through automatic Windows updates. This means that people wishing to deploy to a wide audience without probitively large downloads would have difficulty utilizing log4net, and important packages that depend on it, such as NHibernate. All I can see that would need to be done is move the Asp* files to a second assembly, such as suggested above, and provide a mechanism to have the server pattern converters register themselves as is done in these lines: s_globalRulesRegistry.Add("aspnet-cache", typeof(AspNetCachePatternConverter)); s_globalRulesRegistry.Add("aspnet-context", typeof(AspNetContextPatternConverter)); s_globalRulesRegistry.Add("aspnet-request", typeof(AspNetRequestPatternConverter)); s_globalRulesRegistry.Add("aspnet-session", typeof(AspNetSessionPatternConverter)); It would be a breaking change for the next release, since people would need to reference the second assembly and potentially have a different line of initialization code when web classes are needed. Microsoft has shown that the client profile is very much a first class citizen at this point (even automatically targetting new projects towards it), and it should be supported as such by log4net.
          Hide
          Hugh Anderson added a comment -

          Totally agree with Rober McCarter's comment. I'm working on a Windows client app that won't need System.Web and I do not want to target the full .Net framework profile.

          Please make System.Web an optional component so that non-web-based apps don't need the additional overhead of an unneeded reference.

          Show
          Hugh Anderson added a comment - Totally agree with Rober McCarter's comment. I'm working on a Windows client app that won't need System.Web and I do not want to target the full .Net framework profile. Please make System.Web an optional component so that non-web-based apps don't need the additional overhead of an unneeded reference.
          Show
          Jimmy Sieben added a comment - NAnt is also broken by this issue: https://sourceforge.net/tracker/index.php?func=detail&aid=3050877&group_id=31650&atid=402868
          Hide
          Andrej Golcov added a comment -

          I'll be out of the office from 19.08.2010 till 29.08.2010. For urgent issues please contact Matjaž Hrovat (Matjaz.Hrovat@hermes-softlab.com)

          Show
          Andrej Golcov added a comment - I'll be out of the office from 19.08.2010 till 29.08.2010. For urgent issues please contact Matjaž Hrovat ( Matjaz.Hrovat@hermes-softlab.com )
          Hide
          Ryan Boggs added a comment -

          I tried splitting log4net into something similar as what was recommended by the person who originally reported this issue while investigating the NAnt issue. I even have an (ugly) diff that can output a System.Web free log4net.dll file for reference. My question is if this is the correct approach for this issue?

          Thanks,
          Ryan

          Show
          Ryan Boggs added a comment - I tried splitting log4net into something similar as what was recommended by the person who originally reported this issue while investigating the NAnt issue. I even have an (ugly) diff that can output a System.Web free log4net.dll file for reference. My question is if this is the correct approach for this issue? Thanks, Ryan
          Hide
          Kuno Meyer added a comment -

          As opposed to my original request two years ago, I think that splitting log4net.dll into several assemblies isn't an option. (Due to handling convenience, backwards compatibility and XML configuration issues.)

          Therefore, a better way might be to provide multiple build versions of log4net.dll, one for each environment:

          • .NET 2.0 / 4.0 full installation (the same file as today)
          • .NET 3.5 SP+ / 4.0 client profile (a stripped-down version)
          • (is the compact framework an option? does it need special treatment?)
          Show
          Kuno Meyer added a comment - As opposed to my original request two years ago, I think that splitting log4net.dll into several assemblies isn't an option. (Due to handling convenience, backwards compatibility and XML configuration issues.) Therefore, a better way might be to provide multiple build versions of log4net.dll, one for each environment: .NET 2.0 / 4.0 full installation (the same file as today) .NET 3.5 SP+ / 4.0 client profile (a stripped-down version) (is the compact framework an option? does it need special treatment?)
          Hide
          Ryan Boggs added a comment -

          I don't think I expressed myself correctly in my first post so I apologize for that. I wasn't referring to breaking log4net into separate assemblies. What I meant was to have the ability of choosing which assembly to create, the original one (how it is today) and one with the System.Web dependency stripped out (one that can be used for the client profiles). Based on your response, it sounds like that is the way you are thinking. I can send you my diff so you get an idea on where I am coming from. Of course, I won't expect anyone to use it, just review it.

          Thanks,
          Ryan

          Show
          Ryan Boggs added a comment - I don't think I expressed myself correctly in my first post so I apologize for that. I wasn't referring to breaking log4net into separate assemblies. What I meant was to have the ability of choosing which assembly to create, the original one (how it is today) and one with the System.Web dependency stripped out (one that can be used for the client profiles). Based on your response, it sounds like that is the way you are thinking. I can send you my diff so you get an idea on where I am coming from. Of course, I won't expect anyone to use it, just review it. Thanks, Ryan
          Hide
          Jon S Akhtar added a comment -

          I just added a CLIENT define, and placed it in the correct 7 locations usually "!NETCF && !SSCLI && !CLIENT".

          This builds a client profile version of the assembly. I think that it follows the methodology used to handle the other platform cases, so I don't really see it being a major problem design-wise.

          Show
          Jon S Akhtar added a comment - I just added a CLIENT define, and placed it in the correct 7 locations usually "!NETCF && !SSCLI && !CLIENT". This builds a client profile version of the assembly. I think that it follows the methodology used to handle the other platform cases, so I don't really see it being a major problem design-wise.
          Hide
          Stefan Bodewig added a comment - - edited

          Not strictly a duplicate and came in earlier than LOG4NET-233 but it doesn't make sense to have multiple issues asking for client profile.

          Show
          Stefan Bodewig added a comment - - edited Not strictly a duplicate and came in earlier than LOG4NET-233 but it doesn't make sense to have multiple issues asking for client profile.

            People

            • Assignee:
              Unassigned
              Reporter:
              Kuno Meyer
            • Votes:
              18 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development