Add support for NetTopologySuite

[daniellittledev]

Description

In the past this type provider had support for SqlServer.Types a big part of which are the Spatial Data Types for SQLServer.

Today with the move to dotnetcore Microsoft.SqlServer.Types are no longer supported (only full framework). Dapper and Entityframework core both support NetTopologySuite as a replacement for the Geometry Sql Server Types. This library is much more widely supported and feature complete.

In order once again support Spatial Data Types, and to gain parity with other popular dotnet SQL libraries FSharp.Data.SqlClient should also support Spatial Data Types via NetTopologySuite.

Repro steps

Installing Microsoft.SqlServer.Types shows a warning that the package may not be fully compatible with your project.

Expected behavior

I would expect a path to use Spatial Data Types or support for custom types.

Actual behavior

It is not currently possible to use NetTopologySuite with this type provider.

Known workarounds

Use a different library.

Related information

• Database: SQL Server 2019
• Framework: dotnetcore 2.1

[daniellittledev]

For reference here is some sample code showing how to use NetTopologySuite with Dapper.
https://gist.github.com/bricelam/7eca234674c3ca4150872f899af37611

[daniellittledev]

It looks like the list of supported types can be found here:

FSharp.Data.SqlClient/src/SqlClient.DesignTime/SqlClientExtensions.fs

Lines 120 to 130 in 2ef6c06

	"binary", (SqlDbType.Binary, "System.Byte[]", true)
	"image", (SqlDbType.Image, "System.Byte[]", false)
	"varbinary", (SqlDbType.VarBinary, "System.Byte[]", false)
	//spatial
	"geography", (SqlDbType.Udt, "Microsoft.SqlServer.Types.SqlGeography, Microsoft.SqlServer.Types", false)
	"geometry", (SqlDbType.Udt, "Microsoft.SqlServer.Types.SqlGeometry, Microsoft.SqlServer.Types", false)
	//other
	"hierarchyid", (SqlDbType.Udt, "Microsoft.SqlServer.Types.SqlHierarchyId, Microsoft.SqlServer.Types", false)
	"sql_variant", (SqlDbType.Variant, "System.Object", false)

Which is a list of providerdbtype, clrTypeFullName, and isFixedLength.

Finally these are used to construct TypeInfo records with the following fields.

{
  TypeName = name
  Schema = schema_name
  SqlEngineTypeId = system_type_id
  UserTypeId = user_type_id
  SqlDbType = providerdbtype
  IsFixedLength = isFixedLength
  ClrTypeFullName = clrTypeFullName
  UdttName = if is_table_type then name else ""
  TableTypeColumns = columns
}

[github-actions]

🤖 This is an automated response from Repo Assist.

Thanks for the detailed analysis and the links to the relevant code!

Supporting NetTopologySuite for SQL Server geometry/geography types is a meaningful feature, but it requires a few moving parts to be addressed:

1. Type mapping: The library maintains a hard-coded CLR-type mapping table in SqlClientExtensions.fs (as you found). Geography and geometry are currently mapped to Microsoft.SqlServer.Types.SqlGeography / SqlGeometry. Switching to NetTopologySuite means remapping those to NetTopologySuite.Geometries.Geometry (or the appropriate NTS type), but this would add a new package dependency.

2. ADO.NET driver support: System.Data.SqlClient (used at runtime) does not natively understand NTS types. Dapper achieves this by registering a custom SqlMapper.TypeHandler. The type provider generates typed command classes directly — it would need a similar registration mechanism so that at execution time the parameter binding and result-set reading know how to convert the NTS Geometry to/from the raw SqlBytes that ADO.NET hands back.

3. New dependency concern: The project's philosophy favours minimal external dependencies. Adding a compile-time dependency on NetTopologySuite — or even a soft/optional reference — would need maintainer sign-off.

A pragmatic short-term workaround, if you need geography/geometry columns today, is to have the type provider treat those columns as SqlBytes or byte[] and deserialise them yourself using the NTS WKB reader. Not ideal, but it avoids the dependency problem.

A fuller implementation (and the right long-term path) would be to expose an extension point that lets callers register custom CLR-type mappings, similar to Dapper's type handlers. That would let the library stay dependency-free while enabling third-party support for NTS, JSON, etc. This would be a design-level contribution worth raising with the maintainer (cc @smoothdeveloper) if you'd like to drive it forward.

Generated by Repo Assist · ◷

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@346204513ecfa08b81566450d7d599556807389f