I maintain an Add-in to ArcMap tasked with allowing people to see & edit some native SQL shapes in ArcMap, which of course require working with SqlGeometry and DbGeometry types. Converting between those two types has always generally gone well, until we started exploring migrating ArcMap from 10.6.1 to 10.8.0 & 10.8.1. When run in 10.6, the extension method below returns a valid DbGeometry with a correct SRID (happens to be 102605). But when run in 10.8, the very same method in the very same add-in throws an exception with the message "Cannot set DbGeometry's SRID properly -- 102605 vs 8826".
The add-in operates without problem in production on >100 PCs running ArcMap 10.6.1. The only instances of this problem have been on two test machines running ArcMap 10.8.1. Both of those test machines previously ran 10.6.1 (and handled these conversions just fine), which AFAICT pretty much nails it down to some change in ArcObjects causing this issue. What can cause this? Logging typeof(DbSpatialServices).Assembly.FullName in both environments yields the same: "EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089", so it would seem that the implementation behind `DbGeometry.FromBinary()` should be the same in both places, yeah? That makes no sense to me, so I'm hoping someone else here can help.
Help?
/// <summary>
/// Converts a SqlGeometry into a DbGeometry
/// </summary>
/// <param name="thisSqlGeometry">Geometry to be converted</param>
/// <returns><see cref="DbGeometry"/> instance equivalent to the <see cref="SqlGeometry"/></returns>
public static DbGeometry ToDbGeometry(this SqlGeometry thisSqlGeometry)
{
var dbGeometry = DbGeometry.FromBinary(thisSqlGeometry.STAsBinary().Buffer, thisSqlGeometry.STSrid.Value);
if (dbGeometry.CoordinateSystemId != thisSqlGeometry.STSrid)
throw new Exception($"Cannot set DbGeometry's SRID properly -- {thisSqlGeometry.STSrid.Value} vs {dbGeometry.CoordinateSystemId}");
return dbGeometry;
}
