NameValueCollection Serialization

[Adam Haskell]

I just upgraded my project from 1.4 driver to 1.6 driver and I had a custom serializer for NameValueCollection (we're dumping a bunch of stuff off the HTTP request to report on later). It seems now something is registering EnumerableSerialzer for NameValueCollection. It seemed odd to me that NameValueCollection would get serialized by an Enumerable serializer and not a Dictionary serializer but I was glad to see I could trash my custom serializer. Turns out it looks like the serializer is not storing the collection correctly and (not surprisingly) I am getting an error when it tries to deserialize (Enumerable class NameValueCollection does not implement IList so it can't be deserialized).. 

I'm 90% confident it is not my code registering the faulty serializer but I have to admit to not being able to figure out where that mapping IS happening. I figure I need to figure out how to get my custom serializer in there, fork fix the pull request, or maybe (hopefully) someone can help me out in understanding how EnumerableSerializers are the correct serializer and I just need to configure it correctly.

Adam 

[Robert Stam]

If you register your custom serializer for NameValueCollection the driver should use your serializer.

There is no builtin serializer for NameValueCollection (there probably should be...). 

In the current version of the driver it's being serialized (by default) by EnumerableSerializer because the NameValueCollection class implements IEnumerable and not IDictionary.

[Adam Haskell]

I was originally registering my serializer, but after updating to 1.6 I starting seeing an error on the call to RegisterSerializer. Unbeknownst to me that code is being executed multiple times. 

So solve the above mentioned error I wrapped that registration code with a Serializer lookup:

 if(BsonSerializer.LookupSerializer(typeof(NameValueCollection)) == null) 

The lookup always returned EnumerableSerializer. Seems that was a mistake; Lookup is just finding whatever it would actually end up using and as a result registers that as the serializer. I didn't think about looking to see if RegisterSerializer implemented something different/new to throw errors on duplicated registration (which based off my previous success with this code on 1.4 I am thinking it didn't previously). 

Thanks for re-enforcing my thought that there was nothing explicitly registering EnumerableSerializer for NameValueCollection. For now I've wrapped the code in a try/catch and ignored a Serialization error and I am past that issue. Guess I have a new todo to find why this is being called more than once. Thanks for the help Robert, I'll see if I can figure out the internals enough to add my custom Serializer to the driver itself and generate a pull request (Don't hold your breath though I just moved into a new house so recreational programming sort of on hold right now :(  ) . 

Adam 

[craiggwilson]

Yes, LookupSerializer is probably a poor choice as a name because, while seemingly innocuous, it doesn't communicate the fact that it has an unexpected side-effect of mutating internal state such that you can't change the behavior later.  We will try and address this in future versions.

For now, you simply need to make sure that you call RegisterSerializer at application startup/initialization before any serialization is performed.

[Adam Haskell]

Yeah I was going to ask a follow-up on that and see if there was a less obnoxious lookup method :) Wrapping the code in a try and ignoring the error upon duplicate registration works for now until I can get in there and refactor that stuff to be called only on initialization. 

Adam