After migrating NMoneys (and NMoneys.Exchange) to support .NET Core it is time to lend a little love to the support for serialization via third-party serialization libraries.

This support operates in a very different way than the usual: 1. install package 2. some library is referenced 3. time to code against that library as it comes in the shape of source code that are added to your solution and compiled as part of it.

How it was done

When I started supporting third-party serialization I made a misguided choice.
Yeah, I admit I was wrong when I removed the dependency on the supported serialization libraries. In my brain, taking a dependency meant: "whenever a package was update I would need to update mine". That really is not how it works at all.
Taking a dependency means: "in order for my code to work, I need to have at least this other library version in place". If a newer version comes up, the default reaction is "alright, my library should continue working with that newer version". That is, as a package author, one does not have to upgrade package dependencies with every new version of the dependency.
The only case I can think of that will break this "leave-version-as-it-was" happiness, is when a newer version of the dependency actually breaks your code. One can have an optional release with the old code and a dependency maximum version, but from then on, a newer version of your package needs to be released pointing to the version of the dependency that broke your code, thankyouverymuch.

Besides not taking a dependency I delivered my code as source code. That is, my code is part of your solution and you are happy to change it or delete some of it.

One of the things I usually did every now and then was to install newer versions of the library and checking whether the tests still passed.
That was a totally manual and transient process: install the new version of the dependency in the test project, run tests and rollback changes when everything is green (or get rid of the branch, if I bothered to create one in the first place).

Upgrading is always fun

Big change came, with the .NET Core support, so thought I would test whether the serialization artifacts worked in netcore projects.
I figured that starting with Json.NET made sense, since I know for sure they support netcore.

As the serialization test project is not a netcoreapp project, I created a new netcoreapp project in the command line and proceeded to install the packages for Json.NET and my old serialization package. And then, my newly created project did not compile.
So I went to copy the serialization code in the newly created netcoreapp, compile and... money! It compiles. How odd is that?
Stupid CLI... let's fire up Visual Studio and do like real men do: create a new “.NET Core Console App”, right click “Manage Nuget Packages”, install... wait a minute! Where is my serialization code?
Use Package Manager Console, comfy middle ground… Still not there.

When things get serious, time to hit the Internet...
And then is when I found out that since the inception of .NET Core and its ripple effect on Nuget, files placed under /content will mean nothing to netcore projects.

What I thought it was a routine check, it, once again, turns out to be a rabbit hole. A medium-shallow one, mind you.

While you are down there, love...

So, since I was to rewrite how serialization packages are created, I might as well do the right thing and take a dependency on the serialization framework.

Oh, and since the initial idea was to support newer platforms, why shall I leave the old platforms behind? Let's support multiple frameworks and take the minimum dependency that works for each platform.

Oh, and while you are at it, let's clean the code a bit so that nullable instances are handled properly.

Oh, and, by the way, your serialization code is broken for newer versions of MongoDb. Time to do it properly.

Well, I can repeat myself here, but you might as well read it from the horse's mouth.

End result ≅ Happiness

In this "routine check" I learned quite a few things:

• how to create "modern", multi-platform Nuget packages that contain source code. And I will write further about it
• a new decimal BSON datatype supported in newer versions of MongoDB
• my serialization code still worked (for the most part) with newer versions of the serialization libraries.

Go ahead and get any of the updated versions for third party serialization packages: