On Thursday, October 11, 2012 1:09:03 PM UTC-4, craiggwilson wrote:
> 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.
> On Thursday, October 11, 2012 10:02:03 AM UTC-7, Adam Haskell wrote:
>> 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
>> On Thursday, October 11, 2012 11:23:34 AM UTC-4, Robert Stam wrote:
>>> 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.
>>> On Thu, Oct 11, 2012 at 10:36 AM, Adam Haskell <a.ha...@gmail.com>wrote:
>>>> 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
