SqlClient UDT support needs an assembly-plugin model

I built a .NET Standard implementation of the Microsoft.SqlServer.Types classes. This works great for insertion, but when deserializing I’ll get an exception like this:

Instead I have to write something like:

var binvalue = reader.GetSqlBytes(rowid);
var g = SqlGeometry.Deserialize(binvalue);

This makes sense, because SqlClient has no idea I provided an implementation it could use. Assembly redirect only works for assemblies with the same name and public key, so that’s not really an option. How do we across all the different platforms allow us to use UDT in assemblies defined on each platform, and get the SqlClient to import the types?

The issue is somewhat called out in the doc:

SqlClient may fail to load a UDT in the event of mismatched UDT versions or other problems. (1)

A local copy of the UDT assembly must be available to the client project. (2)

The assembly loaded in SQL Server and the assembly on the client must be compatible in order for the UDT to be created on the client. For UDTs defined with the Native serialization format, the assemblies must be structurally compatible. For assemblies defined with the UserDefined format, the assembly must be available on the client. You do not need a copy of the UDT assembly on the client in order to retrieve the raw data from a UDT column in a table. (3)

In some situations, you may want to retrieve the raw data from the UDT column. Perhaps the type is not available locally (4)

Warning about client side usage of GEOMETRY, GEOGRAPHY and HIERARCHYID

A .NET Standard Implementation of the geometry types for reference which can be used as an example (just tweak unit tests to call GetValue instead of GetSqlBytes on the data reader): https://github.com/dotMorten/Microsoft.SqlServer.Types/blob/89c5e6158867d9603d93fde6286a0f32f01fa96d/src/Microsoft.SqlServer.Types.Tests/DBTests.cs#L81

[divega]

@dotMorten I would vote for keeping this open. I am thinking about what you said in https://github.com/dotnet/SqlClient/issues/1#issuecomment-491994354, and I believe there is still an opportunity to enable plugging in your own types without having to hack with signing.

[bricelam]

Note this is different than the recent open source guidance around strong name keys. It’s a bit of magic for stealing an assembly’s identity without having its private key. This is why strong naming is not about security. 😉