Collection operations fail for entities created via reflection

[object]

I have a scenario when an entity that is sent to Insert or Save methods is instantiated using reflection. In this scenario the type of the entity is not know at compile time, so I can't use generic version of Activator.CreateInstance() and must use Activator.CreateInstance() that returns an object. What happens is if I send this object down to MongoCollection operations, it is treated as "object" because MongoCollection is generic and expects type resolution at compile time. Then the following code in Save method raises NullReferenceException:

        var helper = TypeHelper.GetHelperForType(typeof(T));
        var idProperty = helper.FindIdProperty();
        var id = idProperty.Getter(entity);

In the second line idProperty is null (because "object" type does not have an Id property), and next line raises exception.

My question is: are they reasons to use here and in some other places typeof(T) instead of entity.GetType()? The second form will ensure the type is resolved according its runtime information while the first one relies on static type information and may cause failures like in the scenario above.

[object]

I did some tests: changed typeof(T) to entity.GetType and executed unit tests for NoRM. There were 7 more errors (9 instead of 2 that I had on the latest source), but I was able to save entities created using non-generic Activator.CreateInstance.

If you think this is something that NoRM should support, I can continue looking into it.

[object]

And with more conservative changes I managed to keep the same number of passing tests. So IMHO this is something that can be considered.