Solución:
Tuve el mismo problema y lo solucioné agregando las siguientes líneas al web.config de mi aplicación:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Microsoft.SqlServer.Types" publicKeyToken="89845dcd8080cc91" />
<bindingRedirect oldVersion="1.0.0.0-11.0.0.0" newVersion="10.0.0.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
Esto obliga a EntityFramework a usar la versión 10 de SqlServer.Types.dll, que aparentemente no tiene el tipo Geometry.
Las respuestas anteriores no funcionaron para mí, así que investigué un poco más y comparto mis hallazgos aquí.
Resumen: Hubo un cambio en el Tipos de CLR del sistema de Microsoft SQL Server (SQLSysCLRTypes.msi) entre SQL Server 2012 SP2 (11.0.2100.60) y SP3 (11.0.6020.0) y este problema se puede solucionar actualizando este paquete y cualquier DLL extraviada a la última versión (correspondiente a 2012 SP4 / 11.0.7001.0 al momento de escribir ).
En realidad, solo hay dos cosas en este paquete:
-
Microsoft.SqlServer.Types.dll– la biblioteca contenedora .NET -
SqlServerSpatial110.dll– la biblioteca nativa que contiene la funcionalidad espacial
Tenga en cuenta que innumerables versiones de SQLSysCLRTypes.msi están disponibles, correspondientes a todas las versiones principales / secundarias de SQL Server, pero es molesto que todas se publican con el mismo nombre de archivo y, a menos que realice una instalación completa de SQL Server, tienden a ser requisitos previos manuales para instalar elementos del paquete de características de SQL Server ( por ejemplo, consulte https://www.microsoft.com/en-us/download/details.aspx?id=56041)
Desde la versión SQL 2012 SP3 del paquete en adelante, SqlServerSpatial110.dll exporta la función SetClrFeatureSwitchMap, que se llama desde algún lugar dentro de la DLL contenedora .NET. Antes del SP3, esa función no parecía existir y el contenedor .NET no intentó usarla. (puede enumerar las exportaciones de DLL usando dumpbin /exports <dll file>)
Si el paquete CLR Tipos MSI está instalado en una máquina en particular y una menor La versión de esos archivos DLL se encuentra en el directorio de trabajo de su programa .NET, entonces puede obtener el error. Esto podría suceder fácilmente si distribuye su programa con sus bibliotecas de dependencia para evitar pasos de instalación adicionales para el usuario final.
Siempre que se instalen bibliotecas .NET en el sistema y se incluyan en la caché de ensamblados global (GAC), la versión del sistema siempre ser cargado por un programa .NET incluso si se puede encontrar una copia “local” en el directorio de trabajo. Para las bibliotecas nativas, primero se usa la copia del directorio de trabajo. Esto significa que cuando haces referencia Microsoft.SqlServer.Types en su aplicación y tener ambas DLL de versiones coincidentes en el directorio de su aplicación, si Microsoft.SqlServer.Types está instalado en el sistema con el mismo versión principal (es decir, 11.0.0.0), entonces puede tener problemas cuando intenta cargar sus dependencias de biblioteca nativas y obtiene una versión anterior de SqlServerSpatial110.dll desde el directorio de trabajo en lugar de la versión correcta desde donde esté instalado en el sistema.
Como arreglar: Asegúrese de que las copias de SqlServerSpatial110.dll tener lo mismo versión menor como cualquier copia de Microsoft.SqlServer.Types.dlly asegúrese de tener la última versión de cada uno. Esto probablemente solo se aplica a SQL Server 2012, pero es posible que se produzcan problemas similares en versiones más recientes de SQL Server con eventuales versiones de Service Pack.
Tenga en cuenta que configurar “Versión específica” en “Verdadero” para referencias a Microsoft.SqlServer.Types (en Visual Studio) no tiene ningún efecto, ya que todas las versiones de la biblioteca de tipos CLR de SQL Server 2012 exponen el mismo número de versión a .NET (11.0.0.0), independientemente del service pack al que pertenezcan.
Referencias:
- ¿Cómo puedo obligar a .NET a usar una copia local de un ensamblado que está en el GAC?
- https://docs.microsoft.com/en-us/cpp/build/reference/dumpbin-reference
Entonces, si agrego la siguiente línea de código al inicio de la aplicación, usará la versión SQL 2014 del ensamblaje Microsoft.SqlServer.Types que no parece tener el problema mencionado anteriormente.
System.Data.Entity.SqlServer.SqlProviderServices.SqlServerTypesAssemblyName = "Microsoft.SqlServer.Types, Version=12.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91";
Esto está bien para las máquinas que tienen instalado el SDK de SQL Server 2014.
También envié un error con Microsoft aquí:
https://connect.microsoft.com/SQLServer/Feedback/Details/2139143