Open filipw opened 2 months ago
Hi @filipw, Thank you for raising this issue. This issue has been reviewed and added to our internal backlog for prioritisation . +1s and pull requests will help this move upward our backlog
Issue for tracking : https://twilio-engineering.atlassian.net/browse/DII-1699
Thanks, Athira
Hi team, Can we fix this issue for .NET 8. Is it possible to make a target .NET 8 libraries only as it is the end of 2024 and its time as .NET 9 is coming in a few weeks ...
P.S it affects our prod build as security scans create errors messages.
Hi,
Any update as this screwing our production builds ... It is just a simple 10 sec fix by removing
Also, this is not an enchantment, but a bug. The current library build doesn't dependents on that old package at all
+1 please prioritize this issue.
Hi guys, how hard is it to remove one line from Twilio.csproj line 43 and build again? Its needs 3 months of scrum meetings with hours of discussions what to do next , I guess :)
+1
Issue Summary
At the moment the library does not explicitly target .NET 8.0.
This means, that referencing it from a .NET 8.0 application means going over .NET Standard 2.1, which in turn pulls a ton of very old (dating back to 2016) dependencies via System.Collections.Specialized, some of which even have CVEs on them.
Taking this into account, and given that .NET 6.0 reaches end of life in November this year, it would be good to add .NET 8.0 to multi-targeting.
Additionally, the System.Collections.Specialized should also be dropped as explicit Nuget package reference for .NET 6.0 and .NET 8.0 as it's not needed there (the necessary types are already available).
Steps to Reproduce
<NuGetAuditMode>all</NuGetAuditMode>
dotnet publish -r linux-x64
Technical details: