Missing pieces before NLog 5.0 release candidate

[snakefoot]

Have now made a draft document of the upcoming release:

NLog/NLog.github.io#158

Have the following tasks remaining:

• Extract Msmq-Target into NLog.Msmq-package (and drop NLog.Extended-package)
• Extract Wcf-Target into NLog.Wcf-package
• Extract Mail-Target into NLog.SmtpClient-package
• Extract Database-Target into NLog.Database-package Extracted DatabaseTarget into NLog.Database with help from ValueTypeLayoutInfo #4351
• Extract Network-Target (Along with NLogViewerTarget + ChainsawTarget) into NLog.NetworkSocket-package
• Extract HostNameLayoutRenderer into NLog.NetworkSocket-package
• Extract LocalIpAddressLayoutRenderer into NLog.NetworkSocket-package
• Extract WebService-Target into NLog.WebRequest-package
• Extract PerformanceCounter-Target into NLog.PerformanceCounter-package
• Extract PerformanceCounterLayoutRenderer into NLog.PerformanceCounter-package
• Extract ImpersonatingTargetWrapper into NLog.WindowsIdentity-package (if possible)
• Extract WindowsIdentityLayoutRenderer into NLog.WindowsIdentity-package
• Extract OutputDebugStringTarget into NLog.OutputDebugStringTarget
  - Leave behind DebugSystemTarget that can call System.Diagnostics.Debug.WriteLine
• Extract RegistryLayoutRenderer into NLog.WindowsRegistry-package
• Remove QueryPerformanceCounterLayoutRenderer
  - The layout is called ${qpc} which also doesn't give much meaning.
  - Maybe call it NLog.HighPrecisionTiming since nothing to do with Windows PerformanceCounters.
  - But that name is also misleading since there is no high precision because the layoutrender infers a huge overhead.
  - Think it should be removed and one should instead use ${scopetiming} or ${processtime}
• Layout<T> should be merged with Added Typed layout #3656 Typed Layout for easy conversion from Layout to simple value #4306
• Add support for better type-name loading to resolve Extend NLog target extension type-name loading #2944
• Add support for dependency injection of singleton services through LogFactory.Setup().SetupExtensions()
• Add support for fluent setup of NLog-configuration - LogFactory.Setup().LoadConfiguration() with fluent creation of NLog-LoggingConfiguration #4323
• Obsolete NLog.Fluent and introduce optimized LogEventBuilder - Introduced LogEventBuilder instead of NLog.Fluent.LogBuilder #4325
• Remove build and publish of NLog.config-nuget-package
• Major version bump to 5.0-preview1 and publish nuget-package - NLog 5.0 preview 1 with strong-version 5.0.0.0 #4468
• Issues that need attention after releasing NLog 5.0 Preview 1 (needs documentation on wiki)

[snakefoot]

Because of Travis-build-pipeline issues, then waiting for #4271 to be approved and Travis being disabled for this project.

[snakefoot]

@304NotModified Since we are working on extracting exotic stuff from the NLog-package. Would it be a big issue if the QueryPerformanceCounterLayoutRenderer ${qpc} was just dropped into the sea of the forgotten? (Without it being extracted into its own nuget-package, see also my doubts about this package in the todo-list above).

[snakefoot]

@304NotModified Thinking that it might be an idea to create a meta-package for the NLog-project, that includes the following nuget-packages:

• NLog
• NLog.Database
• NLog.NetworkSocket
• NLog.WebRequest
• NLog.SmtpClient
• NLog.HttpClient (one day)

The meta-package should automatically bump its version, whenever updating one of its dependencies. It could be done by not moving these dependencies out of the NLog-repository. But try to ensure they don't have Windows-specific unit-testing.

[snakefoot]

Starting to convince myself that a lot of the convenience with NLog is lost when extracting these into seperate packages:

• NetworkTarget.cs
• MailTarget.cs
• WebServiceTarget

Did a comparison of adding NLog to a simple ConsoleApp with AppTriming and SingleEXE. It grew from 11 MByte to 21 MByte. When using NLog without the above packages then it became 19 MByte. Think NLog needs to be re-assembled completely if wanting to reduce its dependencies.

Maybe it should just be an exercise in removing Windows-specific stuff from the respository so people on other platforms can approach the Nlog-project. Along with removing DatabaseTarget to fix the code-analysis warnings because it can execute SQL.

[304NotModified]

Thinking that it might be an idea to create a meta-package

I like meta packages. Best if both worlds. I think the metal package should be called NLog and the "core" NLog.Core

[304NotModified]

Starting to convince myself that a lot of the convenience with NLog is lost when extracting these into seperate package

What's lost if we've a meta package?

[snakefoot]

I have decided to bravely revert the changes of extracting MailTarget + NetworkTarget + WebServiceTarget, so they become part of the default NLog-project (again).

Will instead just focus on extracting the database-target and the other exotic targets that are very Windows specific. To make the NLog-project approachable from other operating systems than Windows.

Made some stabs on stripping all targets and all layoutrenderers from the NLog-project, and still the AppTriming could not reduce below 19 MByte. Think somebody has to take a microscope and check parts of the NLog-infrastructure that prevents triming.

[snakefoot]

What's lost if we've a meta package?

That it just generates a lot of inconvience without providing any real benefit. Lots of loosers and no winners.

[304NotModified]

The real benefit is that an user could choose to include less targets. That is also nice for security reasons.

Also I think in the future those should be separate repositores and builds, so the build don't take ages.

[snakefoot]

That is also nice for security reasons.

Since NLog doesn't start doing random things on its own, but only perform logging to the targets that has been configured. Then I don't see this an issue. The only security issue that I see is the automatic assembly loading, and that will now be disabled in NLog 5.

I'm not going to revert everything, but I will just let WebServiceTarget and MailTarget glide back into the NLog-project. Neither of them gives any overhead in the build-process.

[snakefoot]

Believe the remaining pieces for completing NLog 5.0 are now ready as pull-requests.

[snakefoot]

Now just need #4351 for extracting DatabaseTarget into its own nuget-package.

[snakefoot]

@304NotModified So that's what I mean before, maybe trim the milestone

Have now removed all my own issues where no pull-request is ready. Maybe you could do the same?

[304NotModified]

Yes, will do that

[snakefoot]

Yes, will do that

You want me to move the outstanding issues to NLog 6.0 ?

[snakefoot]

All checkboxes has been ticked. Created #4468 with major-version bump to 5.0-preview1

[snakefoot]

Issues that need attention after releasing NLog 5.0 Preview 1 (needs documentation on wiki)

[snakefoot]

Completed updating the necessary wiki-pages, but left one for @304NotModified to complete.

[snakefoot]

Closing since NLog 5.0-rc1 is now out. Still waiting for pending wiki-update: #4716