Yet it exhibits one frustrating behavior when one of the objects is masked by an NHibernate proxy,
as it starts to go off the rails and soon the JSON code is riddled with __interceptors, and EventListeners,
and various other critters that have no purpose being sent across the wire.

(Yes, arguably I shouldn’t be directly serializing these NHibernate objects, but the DTOs I would use
would look remarkably similar to the NH objects they would attempt to mock.)

The problem comes with the chaining of strategies a JsonSerializer uses to determine how to serialize a particular strategies.
This chain is captured by the DefaultContractResolver in the CreateContract(Type) method (which thankfully and
wisely is also virtual): it tries in succession to figure out if the type is a primitive, if it’s decorated with Json*Attributes,
if it’s a dictionary, etc, and eventually it just gives up and creates a plain JsonObjectContract.

However, in the middle of that chain is a test for whether the type is ISerializable, and unfortunately the NHibernate proxies
happen to have that attribute, and that is what causes the serializer to go down a rabbit hole.

My solution is to force it to use a JsonObjectContract when it encounters one of these proxies.

I am not sure whether the condition is too restrictive or may generate false positives, but all the NH proxies I’ve encountered
seem to exhibit the same behavior: they are auto-generated classes, without a namespace.

So? Liked it? Hated it? Thought it was stupid? Thought I was stupid? Deemed it to be informative? Want to lavish excessive praise or cast fiery insults? Contact me and have at it.