this post was submitted on 09 Aug 2023
197 points (99.5% liked)
.NET
1466 readers
7 users here now
Getting started
Useful resources
IDEs and code editors
- Visual Studio (Windows/Mac)
- Rider (Windows/Mac/Linux)
- Visual Studio Code (Windows/Mac/Linux)
Tools
Rules
- Rule 1: Follow Lemmy rules
- Rule 2: Be excellent to each other, no hostility towards users for any reason
- Rule 3: No spam of tools/companies/advertisements
Related communities
Wikipedia pages
- .NET (open source & cross platform)
- .NET Framework (proprietary & Windows-only)
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
If your usage is that ingrained, the other option is to fork it and drop the dependency, or swap to any of the already-numerous forks that do so. Unless there's licensing concerns with that approach?
You're relying on the fork to remain maintained, or else you risk you run into build/functional issues at some undetermined point in the future when it becomes incompatible with other changes in your environment/project. If you don't trust the fork will be maintained, you should begin decoupling your project from the library anyway. I would be more willing to trust an alternate (or no) mocking framework over a Moq fork to be supported in the long term. That might change in a couple months if one becomes established.
I would personally wait a couple months, or until the original Moq creator reverses course. (If he does that, I think it's unlikely a fork will compete with the original, so I'd start removing the dependency as I can't trust the author anymore.)