2

When I've built a shared .NET library in the past (for internal use, not a public library), I've embedded a serialization library (usually Newtonsoft) as a resource and used assembly resolving to load it in a manner similar to Embedding DLLs in a compiled executable. I've done this so the users of the library aren't forced to worry about the version of Newtonsoft that the library was built with.

In a .NET Core world, is this still a good approach? It seems like with the deep inclusion of NuGet, it might not be needed anymore, but I haven't built a large enough number of .NET Core applications to know how bad dependency graph management can get.

svick
  • 214,528
  • 47
  • 357
  • 477
Erick T
  • 6,313
  • 6
  • 38
  • 78
  • What different about serialization dependency and any other dependency? Do you have a requirement that the whole application has to be a single executable file? – svick Jun 29 '16 at 18:21
  • The main difference is that serialization and logging are two dependencies that almost every project will have. I have spent many days fighting N dependencies that all specify a different version of log4net (or Newtonsoft) in the NuGet specification, usually resorting to assembly binding redirects. – Erick T Jun 29 '16 at 18:23

1 Answers1

2

I have moved away from doing that. The ability to specify dependencies and which specific versions of them are required makes it more explicit to consumers (ours is only for our team) that there's a dependency. Having dependencies being less explicit has lead to headaches for us, especially with larger applications as keeping your binding redirects all happy can become an issue. Might as well keep it easy for yourself to remember that you might need some other package and which version has been successfully integrated by using the nuget dependency management in the nuspec.

dwbartz
  • 885
  • 10
  • 13