add updates to devops, nuget, packages, readmes and sdk #41
Conversation
BenjaminAbt
commented
Dec 17, 2023
•
BenjaminAbt
commented
- add new nuget csproj requirements
- update sdk to .net 8
- remove .net 6
- add .net 7 and net 8 as monikers
- update devops steps
| @@ -3,17 +3,23 @@ | |||
| <PropertyGroup> | |||
| <Product>HTTP User Agent Parser Extensions for IMemoryCache</Product> | |||
| <Description>HTTP User Agent Parser Extensions for IMemoryCache</Description> | |||
| <TargetFrameworks>netstandard2.0;netstandard2.1;net6.0</TargetFrameworks> | |||
| <TargetFrameworks>net7.0;net8.0</TargetFrameworks> | |||
There was a problem hiding this comment.
Why is explicit net8.0 needed?
We don't use any features from .NET 8, so this is just a build target w/o any real use.
Same question on the other places too.
There was a problem hiding this comment.
OK, I know the reason now 😉.
There was a problem hiding this comment.
@gfoidl What is the reason? Thought it does not make a difference if a library ist .net6 or .net8 as long as it is consumed in a .net8 application.
There was a problem hiding this comment.
@stefannikolei the ILCode can now change as the .NET compiler now incorporates certain features into the ILCode. In our case here there should be no changes.
Specifying the multiple monikers is actually the recommended way (today). Analyzers and tools - even NuGet - only show your library as a "compatible target framework"; otherwise the fallback to "computed".
https://medium.com/medialesson/compile-net-libs-for-multiple-target-frameworks-499b21505789
Unfortunately, there are also third-party tools that issue a warning if - as in our case - the package is still for .NET 6 (although it still has 10 months of official support) -> breaking change in the version bump.
Functionally nothing has changed in this update. So if you still need .NET 6, you can simply stay on 2.x.
