Closed SandGrainOne closed 10 months ago
The SonarCloud Quality Gate passed, but some issues were introduced.
2 New issues
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code
This is more a «drop net6.0 support» than a «add net8.0 support», but that is likely a good thing.
Only downside I can see is that if we get a security issue, we’d need to release a fixed version for net6.0 also, as many apps still uses it.
If I'm missing something I'd like to know. I haven't done any thorough testing, but I get both Events and Profile to start. Those are dotnet 7 and 8 respectively.
I'm pretty sure I have had issues referencing a library that only targets net8.0 from a project that targets a lower version. How did you test? You have presumably not published this version to NuGet? Did you somehow use a way to override the compatibility check locally, or just not noticed that an older version of the library was used?
I opened the package as a zip file and ensured that there is both a net6 and net8 folders with their own dll.
Did you delete the bin folder after changing the target framework? I think dotnet pack
just copies everything that is there, so your net6.0 version won't receive updates, and won't be created on CI vms.
You can multitarget to get dlls for multiple framework versions, but then you'll need to explicitly list the versions in <TargetFrameworks>
(notice the s
).
I did add a <TargetFrameworks>
to the AccessToken project. AccessTokenClient is already standard2.0.
Seems like I did not read the diff closely enough. A test project was updated to net8.0 (no multi targeting) and my comments was based on that. So sorry. This looks good.👍
@tba76 @acn-sbuad I need input on versioning of this. My suggestions: AccessTokenClient -> v1.3.0 (current 1.2.0-preview.1) AccessToken -> 4.0.0 (current 3.1.0-preview)
Description
Adding dotnet 8 support.
Related Issue(s)
74
Verification