Upstream patched package dependencies

Jul 1, 2011 at 2:44 AM
Edited Jul 1, 2011 at 2:45 AM

Here's my situation:

  • I publish PackageA
  • PackageA depends on PackageB, which is written by somebody else
  • I've discovered an issue in PackageB that is hard to work around from the code in PackageA
  • I've forked and patched PackageB but the maintainer is yet to merge my patch and ship a new version

How do I handle this?

Idea 1:

  • Release PackageB-WithFooFixes to the public NuGet feed
  • Make PackageA dependent upon PackageB-WithFooFixes instead of PackageB

Downside: Gets messy, fast. And I don't want to try and rebuild their package (it has multiple framework builds, SL, WP7, etc)

Idea 2:

  • Add my forked version of PackageB.dll as an assembly reference
  • Remove the PackageB dependency from the PackageA nuspec
  • Ship PackageB.dll inside PackageA

Downside: Stuffs up any down stream consumers who want to use PackageA *and* PackageB directly (which is quite possible)

Idea 3:

  • Incessantly hassle Mr Sheehan until he merges my pull request ... ;)

Downside: He's too nice for me to do that.

Idea 4:

  • Email this list and hope somebody has a better idea
Jul 1, 2011 at 6:09 AM

Not sure there is a great way to handle this. #1 is definitely dirty. #3 is ideal, but if you can't wait, maybe you can do a variant of #2 where you name PackageB.dll something else, or even IL merge it into your assembly to avoid confusing others. You really don't want anyone else to use your build of PackageB.dll directly.

Jul 1, 2011 at 5:17 PM

I’ve run into this situation with Log4Net. They’ve accepted my patch submission but haven’t yet released a new version (in years it seems).

So what I did was navigate to this directory:


Replaced the log4net.dll with my patched one. Checked it in.

What I’m counting on is that if 1.2.11 is *ever* released, I’ll just need to update my project and I’ll get those changes.

Downsides of course are:

1. Doesn’t help anyone else. I’m not too worried about this because I might be the only one to really care about my patch.

2. Log4Net might never release a new version. Again, not a big concern because I’m still ok.

3. Log4Net might release a newer version without my patch. Now this would suck. In this case, it seems unlikely because they’ve already incorporated the code. But in the general case, this is entirely possible. If this happened, I’d have to patch the new version and repeat these steps.

Now this only addresses the case where I’ve installed Log4Net as a consumer. Tatham’s case is more interesting because he’s writing a package that depends on the package that needs a patch.

For example, if I am building SuperLogger -> Log4Net 1.2.10, but SuperLogger needs a patch, one crazy idea would be to include support for patch dependencies.

SuperLogger 1.0 -> Log4Net 1.2.10, Log4Net 1.2.10.patch

When Log4Net 1.2.11 comes out, you can remove the patch dependency.

SuperLogger 1.0 -> Log4Net 1.2.11

What would the patch package do? It simply replaces any components of the package that it’s a patch for. The benefit is that if Log4Net 1.2.11 comes out independently, you could update that and the patch would no longer apply and would no longer replace components of log4net.


Jul 1, 2011 at 7:11 PM

In cases where that doesn't work out, #1, while painful, isn't really that dirty. I believe the concept is generally accepted in other pkg mgmt systems where people create a custom package and somehow tag themselves to the custom one (I've heard of suffixing the package with their username).
"Be passionate in all you do"