The CSharp driver appears to have a bug with the new default to V3 Guid handling.
If I have a property with children of type object containing UuidLegacy guids, e.g.
public List<object> MyList { get; set; }
public Dictionary<string, objecdt> MyDict{ get; set; }
The driver will use the ObjectSerializer, which always makes a default GuidSerializer for objects of type Guid (see ObjectSerializer.cs line 80). Even if you register an ObjectSerializer instance to use GuidRepresentation.UuidLegacy on program startup, dictionary and list serializers will still use a default instance.
It is true that it is a quirk of the ObjectSerializer that it does not lookup a GuidSerializer in the registry but instead uses its own copy that is configured separately. See CSHARP-5498.
I am unable to reproduce your claim that List and Dictionary serializers don’t use a registered ObjectSerializer. I wrote a test for that and verified that List and Dictionary serializers DO use a registered ObjectSerializer.
Thank you for looking into this. I realized after further testing and reviewing the MongoDB source that my key shortening dictionary serializer was initing it’s own object serializer instead of fetching the registered serializer. I tried to update my comment but it was still in moderation and I didn’t get a notification in time to add to it. I apologize for wasting your time.
One other minor gotcha in the 3.x library is if you’re trying to construct a BsonDocument to send as a query to a collection with type 3 guids the drop of support for Guid in BsonValue.Create means an extra wrapper test to explicitly construct a BsonBinaryData.
It might be helpful if these quirks were part of the article on Guid handling in the new driver version.
Thanks,
Peter
Hi @Peter_Sidebotham,
No problem. We’ll make sure to relay this to our docs team so we can add some details around it to our GUID page. Glad to hear your original issue was resolved.
Thanks,
Rishit.