5 ms·
From the linked (Aaron's) post: > .NET users need to culturally normalize the idea of adopting non-Microsoft .NET solutions when those third party technologies
by zvrba 7y ago
From the linked (Aaron's) post:
> .NET users need to culturally normalize the idea of adopting non-Microsoft .NET solutions when those third party technologies are better on the merits.
I'm a .NET developer and say: no. If Microsoft's solution satisfies my needs, I won't adopt a 3rd-party solution, especially if it has other nuget dependencies. Managing nuget packages can become hellish (looking at you Newtonsoft.Json) and MS at least takes some care with that.
I'm icky about adding dependencies and by using MS's solutions I can be relatively sure that they won't depend on latest shiny OSS package that could become a liability in the future.
- reallydontask 7y agoI'm with you on this one. I will say though that the issue I find is that sometimes this can lead to convoluted code Picture this scenario: Start using MS package and all is good One day a new requirement comes in that the package just can't handle so you code around it. Turns out that an open source package did what you wanted all along in a much neater way. This has happened to me a few times that I'm aware of, no doubt countless others where I'm not aware of it.
- tybit 7y agoI think to be fair even Microsoft doesn’t get this right consistently. For example EF, particularly EF Core has been a nightmare IME. Whereas Dapper has consistently delivered over time (props to StackOverflow for their awesome and consistent OSS contributions).
- zvrba 7y agoYes, choosing EF Core is one of my biggest, if not THE biggest, regrets on the project I'm working on. Not because of the way it's packaged but because.. it's a heavy-weight ORM that stands in the way of using the database as a database. I want to write my queries in SQL and automatically map results to classes or even maps with correct types.
- Nullabillity 7y ago> Managing nuget packages can become hellish (looking at you Newtonsoft.Json) and MS at least takes some care with that. So.. MS wrote a horrible package manager, and the workaround is to use more MS products?
- deleted 7y ago[deleted]
- zvrba 7y agoSo which package manager is NOT horrible when it comes to handling conflicting dependencies? Esp. when combined with developers specifying wrong constraints for dependencies, either out of cluelessness or carelesness?
- ClumsyPilot 7y agoI think the problem is the wrong way round -> .Net developers are still, to some extent, getting used to contributing open source code. Most .Net developers I know never submitted pull request to a public OSS project, whereas in JS world, everyone and their dog seems to be doing it. (and half of the packages are rubbish, but I am getting sidetracked..) Many non-MS OSS packages / libraries only have like 1 or 2 maintainers. If they no longer have time for it, or, god forbit, get ill/life happens, then you've got a dead dependency. I never discriminate against a well-supported OSS package in favour of a Microsoft one.