Skip to content
This repository was archived by the owner on Feb 12, 2025. It is now read-only.

Add support for NET 8.0 #316

Open
RomanLeonB opened this issue Dec 17, 2024 · 5 comments
Open

Add support for NET 8.0 #316

RomanLeonB opened this issue Dec 17, 2024 · 5 comments
Assignees

Comments

@RomanLeonB
Copy link

RomanLeonB commented Dec 17, 2024

Describe the problem to solve
I want to add NLog.Targets.Syslog to a NET 8.0 application

Describe the enhancement proposed
Upgrade *.csproj to NET 8.0

I can also upgrade the *.csproj files if that's okay with you.

@RomanLeonB RomanLeonB changed the title Support for NET8 Add support for NET 8.0 Dec 17, 2024
@snakefoot
Copy link
Contributor

Maybe just remove net6.0 and just rely on netstandard2.0 ?

@RomanLeonB
Copy link
Author

RomanLeonB commented Dec 18, 2024

I think this is not possible, because TestAppWithGU and TestAppWithTUI does explicitly use net6.0 or net6.0-windows
Or do you mean to set all targets to netstandard2.0?

My suggestion:
Remove net6.0 support in FakeSyslogServer
Remove net6.0 support in NLog.Targets.Syslog.Schema
Remove net6.0 support in NLog.Targets.Syslog
Upgrade TestAppWithGUI to net8.0
Upgrade TestAppWithTUI to net8.0

RomanLeonB pushed a commit to RomanLeonB/NLog.Targets.Syslog that referenced this issue Dec 18, 2024
RomanLeonB pushed a commit to RomanLeonB/NLog.Targets.Syslog that referenced this issue Dec 18, 2024
RomanLeonB pushed a commit to RomanLeonB/NLog.Targets.Syslog that referenced this issue Dec 18, 2024
RomanLeonB pushed a commit to RomanLeonB/NLog.Targets.Syslog that referenced this issue Dec 18, 2024
RomanLeonB pushed a commit to RomanLeonB/NLog.Targets.Syslog that referenced this issue Dec 18, 2024
@RomanLeonB
Copy link
Author

Maybe just remove net6.0 and just rely on netstandard2.0 ?

I may have been too hasty with my solution. Do you agree with my suggestion so that I can create a PR afterwards?

@jasells
Copy link

jasells commented Feb 11, 2025

@RomanLeonB What is the status with this? I have an open issue that may be partially addressed, if retargeted to .netstandard2.0? Generally, I think this is the best option for a lib like this vs. a specific .net Core version target, unless there's something the lib just absolutely needs from .Net Core (6/7/8...).

I certainly would prefer to build on any changes made for .netstandard2.0, and avoid a fork? Glad to see some activity here.

A quick hack on a local copy appears to build fine with only .netstandard2.0 targets for the lib projects, as you suggested, and as I would expect.

It must work, right? 😉

@jasells
Copy link

jasells commented Feb 11, 2025

@RomanLeonB you should be able to just consume this .Net6/standard package in a .Net8 app or lib without changing this lib's target.

That said, IMHO, it would simplify maintenance of this lib to remove .Net6, and just target .netstandard since standard has no sunset of support. .netstandard support policy: https://learn.microsoft.com/en-us/dotnet/standard/net-standard?tabs=net-standard-1-0#net-5-and-net-standard

It also makes the packages a tad smaller since it only contains a single .dll at that point.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants