2 ms·
I have to disagree, C# can be as bad too. I work on a medium-sized (~500k loc) C# codebase, and we get tangled up in dependency chains frequently. It's a web
by vikingerik 4y ago
I have to disagree, C# can be as bad too. I work on a medium-sized (~500k loc) C# codebase, and we get tangled up in dependency chains frequently. It's a web app with a number of integrations and API calls for things like Google/Facebook/Bing ads that each use some library from them, and other stuff like cloud storage calls and FTP file deliveries. They all tend to bring in more dependencies, like Newtonsoft Json parsing, Excel reader/writer classes, HTTPS and certificate management libraries, log4net logging. I spend a non-trivial amount of time sorting out version conflicts among these, even with the Nuget package manager doing most of the work.
- andyp-kw 4y agoI don't understand how any of the libraries you mentioned would cause dependency issues unless you're referencing them in a weird way. Nuget packages are usually compiled and self contained with their dependencies.
- vikingerik 4y agoWhat happens is version conflicts. The dependencies often want to bring in conflicting versions of the grand-dependencies, the lower level libraries like Newtonsoft.Json and log4net and so on. There's a <bindingredirect> syntax in web.config or app.config that allows telling something to look for a different version. This usually works, and Nuget gets it right automatically most of the time, but occasionally there's a real conflict where a version isn't compatible and I spend a day a few times a year dealing with that.