I have already touched the subject of NMoneys serialization in the context of a third party serialization library.
Even a custom converter was released as a Nuget package. But real world experience taught me it is not enough.

A new model

I have always been hesitant on the policy to adopt when depending on third party libraries in my packages: shall I fix it to a known version? Fix the upper limit to the next semantic version and hope for the best? Update the minimum version every now and then?
Quite a few questions and few definitive answers.

In this particular case (serialization using a Json.NET converter), I chose to break with the past and deliver the custom converters and everything else as source code and remove the dependency to the serialization framework from my package.
Is this the way to go? It definitely has its advantages, but time will tell.

New horizons

A side effect of the decision is allowing the user of the package to tweak the serialization process or remove the artifacts that won’t be used.
It also gives me the opportunity to supply the same code for Json.NET and RavenDB (that uses an internalized version of the former) just by switching namespaces during the build process.