Remove out of support target frameworks in tests and samples

[0xced]

• Add .NET 6 target framework instead
• Update tests and sample dependencies
• Simplify conditional package references in all projects
• Remove the custom PRIVATE_BIN define, use the built-in NETFRAMEWORK instead
• Also use the Visual Studio 2022 image on AppVeyor because VS 2022 is required for the .NET 6 SDK
• Add a reference to Microsoft.TestPlatform.ObjectModel so that dotnet test also works on Linux and macOS for the .NET Framework targets
• Depend on Microsoft.Extensions.Configuration.Binder: there's no need to depend on Microsoft.Extensions.Options.ConfigurationExtensions, taking a dependency on Microsoft.Extensions.Configuration.Binder is enough for what Serilog.Settings.Configuration needs to do.

[nblumhardt]

I'm okay with this change if it makes it easier to maintain this package going forwards. Any thoughts @skomis-mm ?

[nblumhardt]

This change would require a major version bump, e.g. to 4.0.0

[0xced]

You mean, because of dropping the net451 and net461 target frameworks? I have read both .NET fundamentals ⟩ Library guidance ⟩ Breaking changes and .NET fundamentals ⟩ Changes that affect compatibility which give very good advice but none of them mentions dropping a target framework.

[nblumhardt]

Dropping a framework will mean that users on .NET 4.5 (for example) won't be able to install the package, so it'll definitely be a breaking change from a SemVer perspective. I think because it's a big/deliberate breakage it's not really in the scope of what those docs are discussing. Let me know if I'm missing something here, though.

[0xced]

Yeah, you're totally right. I just tried to add those properties in the Serilog.Settings.Configuration.csproj file in order to perform package validation:

<PropertyGroup>
  <EnablePackageValidation>true</EnablePackageValidation>
  <PackageValidationBaselineVersion>3.3.0</PackageValidationBaselineVersion>
</PropertyGroup>

Indeed, this is considered a breaking change. Here's the error after running dotnet pack:

/usr/local/share/dotnet/sdk/6.0.202/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Compatibility.Common.targets(32,5): error PKV006: Target framework .NETFramework,Version=v4.5.1 is no longer supported in the latest version. [serilog-settings-configuration/src/Serilog.Settings.Configuration/Serilog.Settings.Configuration.csproj]

[skomis-mm]

I think unless as it doesn't cost anything from maintanence perspective point of view we can still support older TFM's even if they are eol. Bumping to 4.0 ideally would be good to be done with having some new features first, so it would not took long time to deliver stable release.

[0xced]

I rebased on the dev branch, did the EOL target framework cleanup but only for the tests and sample projects in order not to introduce a breaking change.

[nblumhardt]

Since 6.0 is LTS and brings in fewer dependencies, it might make sense to target it specifically here.

[0xced]

brings in fewer dependencies

What do you mean? After this pull request there are only 3 dependencies, all included unconditionally: Microsoft.Extensions.Configuration.Binder, Microsoft.Extensions.DependencyModel and Serilog.

I see many package authors add net6.0 to the target frameworks and I don't understand why. I see why you'd target .NET 6 if you are making use of new features introduced in .NET 6 such as the new DateOnly and TimeOnly types. If there's no #if NET6_0_OR_GREATER in the code, I don't see the point of targeting .NET 6, but maybe I'm missing something and I'd be happy to be enlightened.

[nblumhardt]

You might be right; I'll need to dig back into it :-)

Last time I checked, I think the NuGet dependency resolution algorithm would mean that a package targeting netstandard2.0 might drag in more transitive dependencies than a package targeting the later TFM, but it's a hazy memory and might not matter here.

Let's leave it out, for now 👍

[0xced]

I think what you are referring to was the situation before .NET Standard 2.0 where many System.* packages were brought in. This issue has been solved with .NET Standard 2.0 so indeed it doesn't matter here. There's a good discussion about that on Stack Overflow: Why does my .NET Standard NuGet package trigger so many dependencies?

[nblumhardt]

Thanks for the pointer; no, I remember the switch away from NETStandard.Library, my memory is of someone coming along after that and demonstrating to me why netstandard2.0 still wasn't the optimal TFM ... 🤔 I'll try to find that thread when I have some time :-)

Recently I've been enabling 5 or 6 when turning on non-null reference type checking, which avoids bundling types from the Nullable package on platforms that already carry them. Not relevant to the change here, though.

[0xced]

Interesting post about .NET Standard 2.0 vs .NET 6 targeting on Stack Overflow for the record: Are there benefits in producing a .NET 6.0 version of a .NET Standard 2.0 library?

[skomis-mm]

Probably we can leave this? Not sure why, but VS on Windows still complaints about missing targeting packs:

C:\Program Files\Microsoft Visual Studio\2022\Preview\MSBuild\Current\Bin\amd64\Microsoft.Common.CurrentVersion.targets(1221,5): error MSB3644: The reference assemblies for .NETFramework,Version=v4.6.2 were not found

[0xced]

Argh! I have amended that in 3f9593e. I use Rider and not Visual Studio, that's why I missed this issue which is common apparently: dotnet/runtime#68716

[skomis-mm]

Looks good @0xced, thanks 👍