3

This question is currently hypothetical, but has a real basis.

NuGet package A by vendor X depends on NuGet package B by vendor Y and System.Runtime by Microsoft.

We have found it necessary to branch B (it's open source) to B' to fix a bug in B that Y is unwilling to fix. Let us say we are several versions behind on B' (this would certainly be true eventually).

Project Q depends on A and B'.

How do I keep nuget from getting utterly confused. I have a script for building nuget cache directories, but it would make a lot more sense if we could just run nuget restore and get the right answer.

In theory we could say we can publish B' to nuget.org, but B is in the way so the upload won't take. There is no chance of convincing X to use our B' instead of Y's B and X is closed source so we can't recompile it.

Joshua
  • 40,822
  • 8
  • 72
  • 132
  • Did you change the package id as well? if you did not, you can specify the exact version in the consuming project (e.g. `2.1.9-internally-fixed`) and live with downgrade warnings. – Martin Ullrich May 09 '17 at 06:07
  • (which would need to be available in an internal feed or directory package source) – Martin Ullrich May 09 '17 at 06:07
  • @MartinUllrich: I am capable of doing that. If you write the whole thing up I can accept such an answer. Right now it's missing pieces but I can kind of imagine what needs to be done. – Joshua May 09 '17 at 15:31
  • you can write a custom `target` to adjust the calculated `ReferencePath` items, remove the wrong one and add yours. I have a similar problem as you, see my solution: [link](https://stackoverflow.com/questions/59498770/how-to-excludedisable-packagereferences-transitivedependency-in-msbuild) – fatfatson Dec 30 '19 at 06:48

1 Answers1

0

If you change the package id, you cannot override package dependencies, if you can, you can create custom versions. NuGet supports SemVer prerelease versions, so you could push a package with the same id to a private feed that has the version 2.1.9-internally-fixed (even add [] brackets to indicate a fixed version dependency) . If make all top-level projects depend on this version, they will override other dependencies. Note that this may cause downgrade warnings if the packages depend on 2.1.9.

Martin Ullrich
  • 94,744
  • 25
  • 252
  • 217
  • So nuget resolved 2.1.9-internally-fixed at compiletime but dotnet build packaged up 2.1.9 anyway. – Joshua Oct 12 '17 at 13:15
  • Did you use NuGet to use the version? check the HintPath elements in the csproj file to see which files are actually used by the build. you can check if NuGet restores the right version if you delete the `packages` directory – Martin Ullrich Oct 12 '17 at 13:58
  • .NET Core: There is no packages directory. There is no HintPath. Dlls are copied directly from the nuget cache to the build output directory. – Joshua Oct 12 '17 at 15:21
  • ah I see. did you do `dotnet nuget locals all --clear`? to make sure you got no old packages with the replacement version? you can then check in `obj\project.assets.json` which package was actually pulled in – Martin Ullrich Oct 12 '17 at 15:26