DapperLib
net461 has reached EOL.
Hello!
.net461 has reached the end-of-life, so far as support from Microsoft. Could you please release a version of Dapper.Strongname that targets net462 or better. Thank you! see Microsoft Lifecycle Info
The net461 version of Dapper already supports net462, net472, net48 etc. We could absolutely change the TFMs, but the only impact that will have is to remove support from some folks. It won't add any. I note that net462 is still in support until 2027 - again, we could change to net462. Is there an actual problem you're seeing with the current setup, though?
You are not restricted to net461.
Hello. Yes - But many organizations check for, and flag, out-of-date dependencies. So, it can prevent compliance with many of those organizations and therefore use of the target library. Also, I believe the recommendation from Microsoft, is that if you are targeting an out-of-support framework, then you should contact the authors and get a version that targets a supported framework version. I just check and the latest version of Dapper.Strongname still targets 4.6.1.
There could be new version that target 4.6.2 and those that wish to stay on 4.6.1 could stay on that by not upgrading. But it would be on those persons\teams that they would be out-of-support compliance.
from Microsoft DevBlogs:
Customers currently using .NET Framework 4.5.2, 4.6, or 4.6.1 need to update their deployed runtime to a more recent version – at least .NET Framework 4.6.2 before April 26, 2022 – in order to continue to receive updates and technical support.
The .NET Framework was previously digitally signed using certificates that use the Secure Hash Algorithm 1 (SHA-1). SHA-1 is a legacy cryptographic hashing algorithm that is no longer deemed secure. We are retiring content that were signed using digital certificates that used SHA-1 to support evolving industry standards.
After looking at download and usage data across the different versions of .NET Framework, we found that updating .NET Framework 4.6.2 and newer versions to support newer digital certificates (for the installers) would satisfy the vast majority (98%) of users without them needing to make a change.
Starting May 2022, we won’t be issuing security updates for .NET Framework 4.5.2, 4.6, and 4.6.1 when we issue these security updates for .NET Framework 4.6.2 and later versions. This means that starting May 2022, if a computer has .NET Framework 4.5.2, 4.6, or 4.6.1 installed, it may be unsecure. Additionally, if you run into any issue and need technical support, you will be asked to first upgrade to a supported version.
There are two completely different things here:
- what a library targets
- what an application targets
When a library targets something, it is purely referencing an abstract targeting pack; there is no functionality, just "here's the API surface I depend on". What matters is what the application target, i.e. your code
- if the application targets net461, then: sure, the application is running at risk, but that's up to you; both your code and the library get whatever net461 contains, for better or worse
- however, if the application actually targets, say, net48, then both the application and the library get net48 (which also happens to implement the net461 API shape)
There is literally no advantage to updating Dapper to target, say, net462. Doing so changes nothing about what code actually runs at runtime; literally the only thing it does is remove choice from people.
If your security team is flagging this library usage as out of compliance, then your security team are ignorant of what any of this stuff actually means, and are making bad decisions from that position of ignorance.
then you should contact the authors and get a version that targets a supported framework version.
It sounds like your proposition, to fix these bad decisions made from a position of ignorance, is to add work (both immediate and maintenance burden) to the open source maintainers. This sounds like fixing the wrong problem, to me.
So: without talking FUD: what actual problem are you trying to solve? If it is "having net461 and nothing higher as a netfx target is a security risk", then: no, just no.
Don't misunderstand me: I've happily removed net461 from a lot of libraries recently, when it started causing actual problems. Just: you haven't cited an actual problem yet.
I am talking about what the library targets. And yes, it is company-driven effort. That said - I get it: It's ultimately your call. I just thought I would make the request. If you think that you will lose a considerable number of adopters that, for whatever reason, could not use a targeted net462 package, then that is your decision to make.
I do appreciate you responding and giving this request consideration. I will figure out plan going forward. Thank you.
Adding a TFM is doable, but I want to emphasize: this does not do what you / your advisor seems to think it does. It will not improve anything re EOL concerns, as long as your application targets something higher.
I'm not emotionally invested here - as I say, I've swapped out net461 in most places already. I don't mind doing it again: it just ... the reasons given here are kinda off-field in this case.
I'll look at the TFMs next time I have the lid up.