3 ms·

C# has assembly binding redirection. https://stackoverflow.com/a/43366172/3679043 https://stackoverflow.com/a/43366172/3679043

by 1wd 6y ago

emn13 6y ago
Yeah, and they're a huge pain if you indeed actually need to use them, and often result in a non-working mess. This wasn't all that uncommon in the early days of .net core, which was particularly bad at this IIRC largely because many foundational libraries were split into packages that essentially could only ever be upgraded in concert. There are a few technical nuances that mean I'm sure this isn't quite the same as the rust case, but it's pretty bad nontheless. Even well thought-out transitions like .net standard weren't free from gotcha's particularly when mixed with multitargeting and deep transitive dependency graphs (which was pretty easy to get in the early .net core days). The whole thing is clearly not great (not just in C#). In particular - many of these problems are entirely artificial. If the type system were sufficiently dynamic, or magically psychic - the problems often go away. E.g. in the rust example - void_c didn't actually change, it was just incompatible because rustc isn't psychic. Even seemingly serious problems like an interface (~ in rust a trait) gaining a new method aren't necessarily fundamentally breaking - as long as you're not calling it. Even truly breaking changes like "best-solution-finder returns a different result and has an incompatible API" might not be breaking between in the case of a diamond dependency pattern as long as the method's side effects allow running both versions - one for each transitive dependency requesting that specific version. Even cases where the break is "real" like a rename, it'd be trivial to consider a shim that allows old consumers to use the new api. In the vast, vast majority of cases in my experience this kind of breakage is a problem due to technicalities. That doesn't mean I have a clue how to solve that, but it does beg the question: isn't it possible for a dependency resolution system to do fundamentally better, here?
- whoisthemachine 6y ago
  In C#, default implementations of new methods on interfaces should at least reduce the pain of additive changes.
- qes 6y ago
  > This wasn't all that uncommon in the early days of .net core Good heavens was that a mess. It had been a nice 15+ years of easy-peasy with dependency management prior to that in MS-land, though. It seemed that a fair amount of the problems were MS learning the pitfalls of how they packaged System assemblies for NuGet. Then the compatibility shim mostly brought things back to what we had been used to in .Net (works) - even easier, in fact, now that automatic assembly binding in builds isn't a minefield.

C# has assembly binding redirection. https://stackoverflow.com/a/43366172/3679043 https://stackoverflow.com/a/43366172/3679043

by 1wd 6y ago

C# has assembly binding redirection. https://stackoverflow.com/a/43366172/3679043 https://stackoverflow.com/a/43366172/3679043

emn13 6y ago

Yeah, and they're a huge pain if you indeed actually need to use them, and often result in a non-working mess. This wasn't all that uncommon in the early days of .net core, which was particularly bad at this IIRC largely because many foundational libraries were split into packages that essentially could only ever be upgraded in concert. There are a few technical nuances that mean I'm sure this isn't quite the same as the rust case, but it's pretty bad nontheless. Even well thought-out transitions like .net standard weren't free from gotcha's particularly when mixed with multitargeting and deep transitive dependency graphs (which was pretty easy to get in the early .net core days). The whole thing is clearly not great (not just in C#). In particular - many of these problems are entirely artificial. If the type system were sufficiently dynamic, or magically psychic - the problems often go away. E.g. in the rust example - void_c didn't actually change, it was just incompatible because rustc isn't psychic. Even seemingly serious problems like an interface (~ in rust a trait) gaining a new method aren't necessarily fundamentally breaking - as long as you're not calling it. Even truly breaking changes like "best-solution-finder returns a different result and has an incompatible API" might not be breaking between in the case of a diamond dependency pattern as long as the method's side effects allow running both versions - one for each transitive dependency requesting that specific version. Even cases where the break is "real" like a rename, it'd be trivial to consider a shim that allows old consumers to use the new api. In the vast, vast majority of cases in my experience this kind of breakage is a problem due to technicalities. That doesn't mean I have a clue how to solve that, but it does beg the question: isn't it possible for a dependency resolution system to do fundamentally better, here?

whoisthemachine 6y ago
In C#, default implementations of new methods on interfaces should at least reduce the pain of additive changes.
qes 6y ago
> This wasn't all that uncommon in the early days of .net core Good heavens was that a mess. It had been a nice 15+ years of easy-peasy with dependency management prior to that in MS-land, though. It seemed that a fair amount of the problems were MS learning the pitfalls of how they packaged System assemblies for NuGet. Then the compatibility shim mostly brought things back to what we had been used to in .Net (works) - even easier, in fact, now that automatic assembly binding in builds isn't a minefield.