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...@gmail.com> on 2020/04/18 14:53:22 UTC

[Log4Net]: resurrection

A short update (not much to report):

- resolved Client profile builds
- can manually build a .nupkg, without any warnings
  - have updated <licenseUrl> to <license>, using the term Apache-2.0, as per the url it was pointing to
  - have updated <iconUrl> to point at the same feather.png the package used to point to online, renamed within the project to package-icon.png for clarity

Next up:
dotnet core tooling wants sdks for net20 and net35 to be installed on the host. Alternatively, we could install all of Build Tools 2019 on the host. I think the former might be neater. At any rate, I now have to figure out enough docker to be dangerous and get a standalone build environment up and running.

-d

Re: [Log4Net]: resurrection

Posted by Matt Sicker <bo...@gmail.com>.
And while I don’t have much experience in .net, I’m fairly experienced with
Jenkins.

On Sun, Apr 19, 2020 at 05:24 Davyd McColl <da...@gmail.com> wrote:

> Thanks, I'll check out the branch.
>
> I have already migrated to SDK-style projects. The one requirement to use
> the dotnet tooling that I'll need to resolve is that the host (docker
> image) will need the .net 2 and 3.5 sdks installed - that's currently the
> only hurdle to building with dotnet.
>
> There is a nuget package from Microsoft which provides the API only (so
> one
> can build) - it contains API for 2 and some 4.x variants. There's a
> 3rd-party nuget package for 3.5. alternatively, I can get mono to provide
> the framework apis, though my current mechanism for doing so doesn't seem
> to be properly picked up for 2.0 or 3.5 (but I can force it with, eg, a
> 2.0-only build and an msbuild prop on the cli). Mono would be nice because
> the project could be built anywhere, but I'm also ok with a windows docker
> image and the 2 sdks installed. Anyways, these are the options I'm
> currently checking out. The docker info in the develop branch will surely
> help, so thanks again.
>
> -d
>
>
> On April 19, 2020 11:11:46 Dominik Psenner <dp...@gmail.com> wrote:
>
> > I must mention that the Dockerfiles are invoked from the Jenkinsfile and
> > uses nant and the nant build scripts to build the project. nant is a
> > deadend road and should be replaced. The dockerfiles could stay,
> providing
> > the future build requisites for the future build scripts. If the project
> is
> > migrated to the new SDK style, it would be supported by the dotnet
> > commandline tool and as such the following targets can be built by using
> > the dotnet build command:
> >
> > https://docs.microsoft.com/en-us/dotnet/standard/frameworks
> > https://docs.microsoft.com/it-it/dotnet/core/tools/dotnet-build
> >
> > This would greatly integrate with msbuild inline tasks which could be
> used
> > to build site and other non-code assemblies:
> >
> >
> https://docs.microsoft.com/en-us/visualstudio/msbuild/msbuild-inline-tasks?view=vs-2019
> >
> > Cheers,
> > Dominik
> >
> > On Sun, 19 Apr 2020 at 10:41, Dominik Psenner <dp...@gmail.com>
> wrote:
> >
> >> You may find the develop and other branches useful:
> >>
> >>
> https://github.com/apache/logging-log4net/tree/develop/buildtools/docker
> >> <
> https://github.com/apache/logging-log4net/tree/feature/netstandard-2.0/buildtools/docker
> >
> >>
> >> There are dockerfiles along with shell scripts that used to work for
> >> building several of the targets.
> >> --
> >> Sent from my phone. Typos are a kind gift to anyone who happens to find
> >> them.
> >>
> >> On Sat, Apr 18, 2020, 17:02 Davyd McColl <da...@gmail.com> wrote:
> >>
> >>> A short update (not much to report):
> >>>
> >>> - resolved Client profile builds
> >>> - can manually build a .nupkg, without any warnings
> >>>   - have updated <licenseUrl> to <license>, using the term Apache-2.0,
> as
> >>> per the url it was pointing to
> >>>   - have updated <iconUrl> to point at the same feather.png the package
> >>> used to point to online, renamed within the project to
> package-icon.png for
> >>> clarity
> >>>
> >>> Next up:
> >>> dotnet core tooling wants sdks for net20 and net35 to be installed on
> the
> >>> host. Alternatively, we could install all of Build Tools 2019 on the
> host.
> >>> I think the former might be neater. At any rate, I now have to figure
> out
> >>> enough docker to be dangerous and get a standalone build environment
> up and
> >>> running.
> >>>
> >>> -d
> >>
> >>
> >
> > --
> > Dominik Psenner
>
>
> --
Matt Sicker <bo...@gmail.com>

Re: [Log4Net]: resurrection

Posted by Davyd McColl <da...@gmail.com>.
Thanks, I'll check out the branch.

I have already migrated to SDK-style projects. The one requirement to use 
the dotnet tooling that I'll need to resolve is that the host (docker 
image) will need the .net 2 and 3.5 sdks installed - that's currently the 
only hurdle to building with dotnet.

There is a nuget package from Microsoft which provides the API only (so one 
can build) - it contains API for 2 and some 4.x variants. There's a 
3rd-party nuget package for 3.5. alternatively, I can get mono to provide 
the framework apis, though my current mechanism for doing so doesn't seem 
to be properly picked up for 2.0 or 3.5 (but I can force it with, eg, a 
2.0-only build and an msbuild prop on the cli). Mono would be nice because 
the project could be built anywhere, but I'm also ok with a windows docker 
image and the 2 sdks installed. Anyways, these are the options I'm 
currently checking out. The docker info in the develop branch will surely 
help, so thanks again.

-d


On April 19, 2020 11:11:46 Dominik Psenner <dp...@gmail.com> wrote:

> I must mention that the Dockerfiles are invoked from the Jenkinsfile and
> uses nant and the nant build scripts to build the project. nant is a
> deadend road and should be replaced. The dockerfiles could stay, providing
> the future build requisites for the future build scripts. If the project is
> migrated to the new SDK style, it would be supported by the dotnet
> commandline tool and as such the following targets can be built by using
> the dotnet build command:
>
> https://docs.microsoft.com/en-us/dotnet/standard/frameworks
> https://docs.microsoft.com/it-it/dotnet/core/tools/dotnet-build
>
> This would greatly integrate with msbuild inline tasks which could be used
> to build site and other non-code assemblies:
>
> https://docs.microsoft.com/en-us/visualstudio/msbuild/msbuild-inline-tasks?view=vs-2019
>
> Cheers,
> Dominik
>
> On Sun, 19 Apr 2020 at 10:41, Dominik Psenner <dp...@gmail.com> wrote:
>
>> You may find the develop and other branches useful:
>>
>> https://github.com/apache/logging-log4net/tree/develop/buildtools/docker
>> <https://github.com/apache/logging-log4net/tree/feature/netstandard-2.0/buildtools/docker>
>>
>> There are dockerfiles along with shell scripts that used to work for
>> building several of the targets.
>> --
>> Sent from my phone. Typos are a kind gift to anyone who happens to find
>> them.
>>
>> On Sat, Apr 18, 2020, 17:02 Davyd McColl <da...@gmail.com> wrote:
>>
>>> A short update (not much to report):
>>>
>>> - resolved Client profile builds
>>> - can manually build a .nupkg, without any warnings
>>>   - have updated <licenseUrl> to <license>, using the term Apache-2.0, as
>>> per the url it was pointing to
>>>   - have updated <iconUrl> to point at the same feather.png the package
>>> used to point to online, renamed within the project to package-icon.png for
>>> clarity
>>>
>>> Next up:
>>> dotnet core tooling wants sdks for net20 and net35 to be installed on the
>>> host. Alternatively, we could install all of Build Tools 2019 on the host.
>>> I think the former might be neater. At any rate, I now have to figure out
>>> enough docker to be dangerous and get a standalone build environment up and
>>> running.
>>>
>>> -d
>>
>>
>
> -- 
> Dominik Psenner



Re: [Log4Net]: resurrection

Posted by Dominik Psenner <dp...@gmail.com>.
I must mention that the Dockerfiles are invoked from the Jenkinsfile and
uses nant and the nant build scripts to build the project. nant is a
deadend road and should be replaced. The dockerfiles could stay, providing
the future build requisites for the future build scripts. If the project is
migrated to the new SDK style, it would be supported by the dotnet
commandline tool and as such the following targets can be built by using
the dotnet build command:

https://docs.microsoft.com/en-us/dotnet/standard/frameworks
https://docs.microsoft.com/it-it/dotnet/core/tools/dotnet-build

This would greatly integrate with msbuild inline tasks which could be used
to build site and other non-code assemblies:

https://docs.microsoft.com/en-us/visualstudio/msbuild/msbuild-inline-tasks?view=vs-2019

Cheers,
Dominik

On Sun, 19 Apr 2020 at 10:41, Dominik Psenner <dp...@gmail.com> wrote:

> You may find the develop and other branches useful:
>
> https://github.com/apache/logging-log4net/tree/develop/buildtools/docker
> <https://github.com/apache/logging-log4net/tree/feature/netstandard-2.0/buildtools/docker>
>
> There are dockerfiles along with shell scripts that used to work for
> building several of the targets.
> --
> Sent from my phone. Typos are a kind gift to anyone who happens to find
> them.
>
> On Sat, Apr 18, 2020, 17:02 Davyd McColl <da...@gmail.com> wrote:
>
>> A short update (not much to report):
>>
>> - resolved Client profile builds
>> - can manually build a .nupkg, without any warnings
>>   - have updated <licenseUrl> to <license>, using the term Apache-2.0, as
>> per the url it was pointing to
>>   - have updated <iconUrl> to point at the same feather.png the package
>> used to point to online, renamed within the project to package-icon.png for
>> clarity
>>
>> Next up:
>> dotnet core tooling wants sdks for net20 and net35 to be installed on the
>> host. Alternatively, we could install all of Build Tools 2019 on the host.
>> I think the former might be neater. At any rate, I now have to figure out
>> enough docker to be dangerous and get a standalone build environment up and
>> running.
>>
>> -d
>
>

-- 
Dominik Psenner

Re: [Log4Net]: resurrection

Posted by Dominik Psenner <dp...@gmail.com>.
You may find the develop and other branches useful:

https://github.com/apache/logging-log4net/tree/develop/buildtools/docker
<https://github.com/apache/logging-log4net/tree/feature/netstandard-2.0/buildtools/docker>

There are dockerfiles along with shell scripts that used to work for
building several of the targets.
--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.

On Sat, Apr 18, 2020, 17:02 Davyd McColl <da...@gmail.com> wrote:

> A short update (not much to report):
>
> - resolved Client profile builds
> - can manually build a .nupkg, without any warnings
>   - have updated <licenseUrl> to <license>, using the term Apache-2.0, as
> per the url it was pointing to
>   - have updated <iconUrl> to point at the same feather.png the package
> used to point to online, renamed within the project to package-icon.png for
> clarity
>
> Next up:
> dotnet core tooling wants sdks for net20 and net35 to be installed on the
> host. Alternatively, we could install all of Build Tools 2019 on the host.
> I think the former might be neater. At any rate, I now have to figure out
> enough docker to be dangerous and get a standalone build environment up and
> running.
>
> -d