Can I change the method parameter type in Sql Builder to object?

[cappuccino8]

I see the error message in sharepoint project.

Dynamic operations can only be performed in homogenous AppDomain.

look into about this. it seems that causes by dynamic type.
So Can I change the method parameter (dynamic parameters) type in Sql Builder to object?

SqlBuilder AddParameters(dynamic parameters);
SqlBuilder Select(string sql, dynamic parameters = null);
SqlBuilder Where(string sql, dynamic parameters = null);
SqlBuilder OrWhere(string sql, dynamic parameters = null);
SqlBuilder OrderBy(string sql, dynamic parameters = null);
SqlBuilder GroupBy(string sql, dynamic parameters = null);
SqlBuilder Having(string sql, dynamic parameters = null);
SqlBuilder Set(string sql, dynamic parameters = null);
SqlBuilder Join(string sql, dynamic parameters = null);
SqlBuilder InnerJoin(string sql, dynamic parameters = null);
SqlBuilder LeftJoin(string sql, dynamic parameters = null);
SqlBuilder RightJoin(string sql, dynamic parameters = null);
SqlBuilder Intersect(string sql, dynamic parameters = null);

TO

SqlBuilder AddParameters(object? parameters);
SqlBuilder Select(string sql, object? parameters = null);
SqlBuilder Where(string sql, object?  parameters = null);
SqlBuilder OrWhere(string sql, object?  parameters = null);
SqlBuilder OrderBy(string sql, object?  parameters = null);
SqlBuilder GroupBy(string sql, object?  parameters = null);
SqlBuilder Having(string sql, object?  parameters = null);
SqlBuilder Set(string sql, object?  parameters = null);
SqlBuilder Join(string sql, object?  parameters = null);
SqlBuilder InnerJoin(string sql, object?  parameters = null);
SqlBuilder LeftJoin(string sql, object?  parameters = null);
SqlBuilder RightJoin(string sql, object?  parameters = null);
SqlBuilder Intersect(string sql, object?  parameters = null);

[mgravell]

That would be preferable, and is parallel to a similar change we made in Dapper's core a very long time ago. I agree there are no technically good reasons for this to be dynamic, and many disadvantages.

I would support investigating this; the main question I'd have here is: does this retain binary compatibility? Yes, dynamic is actually just object with some annotation, but: what happens if we have:

• current library version A, compiled with dynamic
• application code X, compiled against A
• update library to version B, compiled with object
• use application X with library version B without recompiling X

If that works: great, let's do it!

If it doesn't, we need to be more careful, probably making a hard "major" rev with very clear release notes, etc.

My level of concern here is reduced quite a bit by the fact that this is a satellite library, not the core, but we still need to be careful or at least intentional.

Note: I am much less concerned about whether it retains compile-time compatibility; I can't think of any useful scenarios where the dynamic propagation is genuinely useful here, and where losing this would be a loss. I also can't think of any build-breaking cases off the top of my head.