I have no information about who uses log4net and against which framework it runs. It would be great to have this information. There is this:
https://www.microsoft.com/en-us/download/details.aspx?id=6523 {quote} Microsoft .NET Framework Version 2.0 Redistributable Package (x64) [...] *Supported Operating System* Windows Server 2003, Datacenter x64 Edition, Windows Server 2003, Enterprise x64 Edition, Windows Server 2003, Standard x64 Edition, Windows XP 64-bit {quote} I have no access to either one of those operating systems. I've the impression that developers that target an application to one of those operating systems do also have the resources to build log4net from source in the rare case they would need the latest codebase. Note that it is easy to retarget applications to a newer .net framework like 3.5 because the api remained backwards compatible. That's what one should do if he had to make changes to an ancient application. 2017-08-30 17:31 GMT+02:00 Matt Sicker <boa...@gmail.com>: > Oh well, so much for that idea. Do you think net-2.0 is still in wide > enough use to continue supporting it? We moved on from Java 6 to 7 as > baseline requirements for Log4j a while back even though there are still > stragglers using 6, though the idea there is that most users still on 6 > aren't really updating anything anymore other than security patches if > applicable. Would you say it's similar in .net 2? > > On 30 August 2017 at 02:39, Dominik Psenner <dpsen...@gmail.com> wrote: > > > > > On 2017-08-29 16:12, Matt Sicker wrote: > > > >> I'm not too familiar with this area, but would using Windows containers > >> (e.g., via Docker or similar) work here? Or would that only support > newer > >> versions of .net anyways? > >> > > > > Good idea Matt, unfortunately net-2.0 is not available in a windows > server > > docker container as documented in the image variants section at > > https://hub.docker.com/r/microsoft/dotnet-framework/. Only 3.5 and newer > > are available. We already build net-3.5, net-4.0 and net-4.5 with > jenkins. > > I've the impression that if we changed this today, we would gain nothing. > > > > > > > >> On 28 August 2017 at 23:32, Dominik Psenner <dpsen...@gmail.com> wrote: > >> > >> Hi, > >>> > >>> Chris just resolved our infra ticket regarding .net frameworks on the > >>> windows nodes. This is a summary of the outcome: > >>> > >>> Chris Thistlethwaite resolved INFRA-14645. > >>>> ------------------------------------------ > >>>> Resolution: Fixed > >>>> > >>>>> 1. We have observed that none of the windows nodes appear to have > >>>>> > >>>> net-2.0 installed so we cannot build assemblies against it. Is it > >>> possible > >>> to install it on one or more of the windows nodes? It may well be the > >>> case > >>> that it is not possible to have .NET framework 2.0 installed when a > newer > >>> .NET framework is installed on the same windows os. > >>> > >>> 1. All of the Jenkins Windows slaves have .Net 3.5 and .Net 2.0 > >>>> > >>> installed, however in Server 2012 R2 .Net 2 is rolled up into 3.5. I'd > >>> also > >>> argue that building for .Net 2 isn't something we can support if the > >>> tools > >>> at hand only allow newer binaries. > >>> > >>> To me this means that we can no longer build assemblies targeted > against > >>> the framework net-2.0. net-3.5 is the oldest we can get from jenkins. > >>> We'll > >>> have to announce this soon. > >>> > >>> 2. We have observed that windows-2012-3 does not have .NET framework > 3.5 > >>>>> > >>>> installed while the other two Windows nodes have it installed. > >>> > >>> 2. jenkins-win2012-3 has been updated to fall in line with the other > >>>> > >>> nodes. > >>> > >>> This means we will no longer see intermittent build failures because of > >>> the > >>> missing framework. > >>> > >>> 3. As an improvement to the windows node labels we suggest to add > >>>>> > >>>> additional labels that match the installed .NET frameworks. Currently > >>> it is > >>> rather unclear what the windows nodes actually can do and it would > >>> further > >>> allow that not all windows nodes to have exactly the same components > >>> installed. (i.e. windows-2012-1 could have the labels "Windows", > >>> "dotnet-3.5", "dotnet-4.0", "dotnet-4.5", ..) > >>> > >>> 3. Agreed, the windows nodes could use more organized labeling, > however, > >>>> > >>> we're currently keeping them all built out the same (or as close as > >>> possible obviously) so we can maximize the few boxes we have. We just > >>> don't > >>> have enough need to run specific Windows configurations. > >>> > >>> Now that [2] is fixed, all windows nodes have the same capabilities and > >>> therefore this is not an issue. > >>> > >>> Cheers, > >>> Dominik > >>> > >>> > >> > >> > > > > > -- > Matt Sicker <boa...@gmail.com> > -- Dominik Psenner
