Embedding C# libraries as source code

Hi,
I stumbled upon conflicting dll dependencies several times now, and I was wondering how often others do experience the following case:

• There is .NET Lib 'A' (e.g.: well-known JSON.Net)
• There is .NET Lib 'B' using Lib 'A' (e.g.: Configuration Manager)
• There is .NET App 'C' using Lib 'A' and Lib 'B'

The problem arises, when the used versions of Lib 'A' differ for Lib 'B' and the application in an incompatible way.

There are ways to have two different versions of the same .NET library around, but I did not find this to be convenient/safe.

My proposal for those problems: Why not share Lib 'A' as source code? Different versions of the source code would be compiled directly into Lib 'B' and the application.

I did that for my project and wrote a compact JSON serializer. Nuget allows packaging sources, which are added to your C# project conveniently.

I think, this is a nice and clean solution. But still I haven't found many others complaining about conflicting dll dependencies as much as I do. Also, I did not see C# source code packages in general to become very popular. I was wondering, if I missed the down-side.

So, I'm interested in your thoughts. Thanks!

Comments

[Katie Nelson]

Are you using .NET framework or .NET Core? I thought that DLL hell issue was fixed in core.

[pupsette]

IIRC the problem was the same for both targets. I should probably double-check that.

[Katie Nelson]

I would check it Matt. I've been using .NET Core 3.1 and haven't come across any issues. But, I haven't been looking that hard 😊.

[pupsette]

Two possible cases:

1. The dotnet build command outputs error NU1605: Detected package downgrade[...] if for example App 'C' uses an older version of Lib 'A' than Lib 'B' does.

2. The build succeeds, but you may for example experience System.MissingMethodException: Method not found: 'System.Reflection.MethodInfo Newtonsoft.Json.Serialization.JsonContract.get_OnError()'. at run-time. This happened in my case, where App 'C' referenced a newer version of Lib 'A' than Lib 'B' does. This is, because Lib 'B' tries to use methods, which are no longer available or have been moved in the newer version of Lib 'A'.

I tested this with .NET Core 3.1.

[Katie Nelson]

Matt, did this happen after you did a NuGet update?

[pupsette]

Thanks for your feedback, Katie!

Not sure exactly, what you're after. Of course, using the same version in both projects solves the problem. If Lib 'B' and App 'C' are both under your control, that's fine.

The problem is, that whenever you publish an app, there is (usually) only one DLL for each dependency (e.g. to Lib 'A') in your output folder. The build system decides which version to use (or rejects, if the version conflict is obvious).

My personal conclusion: Adding NuGet packages to your library makes it brittle, depending on how widespread and evolving the referenced package is.

[Katie Nelson]

Yes, I understand now. Thanks for clarifying it for me.
Whenever you use someone else's code (through NuGet), it's a gamble on how things will turn out. However, I see it as a necessary evil because I don't want to spend the time to write it myself!

The answer (for me) is test it all thoroughly and when you're done, test it again.