1

I'm having difficulty deploying an console app onto a server.

I am using EF6 (6.3.0) and SqlServerTypes 14 (14.0.1016.290) and initializing before any spatial calls are made as recommended

SqlProviderServices.SqlServerTypesAssemblyName = Assembly.GetAssembly(typeof(Microsoft.SqlServer.Types.SqlGeography)).FullName; //"Microsoft.SqlServer.Types, Version=14.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91";
SqlServerTypes.Utilities.LoadNativeAssemblies(AppDomain.CurrentDomain.BaseDirectory);

However on the setter line, the following error is thrown

System.MissingMethodException: Method not found: 'Void System.Data.Entity.SqlServer.SqlProviderServices.set_SqlServerTypesAssemblyName(System.String)'.

I have made sure that SqlServerTypes dlls are present in the bin directory.

I read that EF6 only supports up to SqlServerTypes 11 which I tried, however no luck there.

App is working fine locally.

Edit: I have now installed SQL Server System CLR Types on the server to no avail.

IronAces
  • 1,857
  • 1
  • 27
  • 36
  • Try upgrading to types v15, make sure you install via NuGet. The other thing to try is compiling as x86, if that works then you are loading the wrong dll at runtime – Chris Schaller Oct 30 '19 at 12:07
  • @ChrisSchaller There is no SqlServer.Types 15.x in NuGet? – IronAces Oct 30 '19 at 14:09
  • 1
    That assembly isn't delivered through NuGet. It's available [through a SQL Server feature pack](https://learn.microsoft.com/en-us/ef/ef6/fundamentals/providers/spatial-support#prerequisites-for-spatial-types-with-microsoft-sql-server). Frankly, given how half-baked spatial support is in EF6, you should consider using [EF Core](https://learn.microsoft.com/en-us/ef/core/modeling/spatial#sql-server) and NetTopologySuite – Panagiotis Kanavos Oct 31 '19 at 14:52
  • In any case, what you posted *doesn't* initialize anything. It tries to *change* the SqlServerTypes assembly used by EF. [SqlProviderServices.SqlServerTypesAssemblyName](https://learn.microsoft.com/en-us/dotnet/api/system.data.entity.sqlserver.sqlproviderservices.sqlservertypesassemblyname?view=entity-framework-6.2.0) though is an *EF* class, not a SqlServerTypes class. The error means you're using the wrong *EF* type - either you used EF 5.0 by mistake, or EF 6.3 removed the property – Panagiotis Kanavos Oct 31 '19 at 15:01
  • @PanagiotisKanavos Thanks for the response. How does this work locally in that case? – IronAces Oct 31 '19 at 15:03
  • Different local libraries. EF 6.1 in the GAC in deployment perhaps, and no EF 6.3 assemblies deployed locally? Post the *full* exception text returned by `Exception.ToString()`. That includes the call stack which would show which method called what and how it ended up trying to call the wrong method – Panagiotis Kanavos Oct 31 '19 at 15:03
  • In any case the error has nothing to do with SqlServer types - it complains about `System.Data.Entity.SqlServer.SqlProviderServices.SqlServerTypesAssemblyName`. That method was added in 6.2, and the [source](https://github.com/aspnet/EntityFramework6/blob/release/6.3/src/EntityFramework.SqlServer/SqlProviderServices.cs#L118) shows it's still available in 6.3. Which means, the *deployed* application tried to use EF 6.1 or earlier. Perhaps you didn't deploy EF 6.3 dlls? Or a leftover binding redirect points to an old EF version? – Panagiotis Kanavos Oct 31 '19 at 15:07
  • PS: Did I mention it's better to use EF Core + Spatial? That's where all future development takes place. EF Core 3 requires .NET Core 3, but you could use EF Core 2.2 in .NET Old just for the entities that need spatial data – Panagiotis Kanavos Oct 31 '19 at 15:08
  • 1
    If you don't want to issue spatial queries from the client, you can use just [NetTopologySuite.IO.SqlServerBytes](https://github.com/NetTopologySuite/NetTopologySuite.IO.SqlServerBytes) to read the geography values as blobs and parse them on the client. – Panagiotis Kanavos Oct 31 '19 at 15:11

1 Answers1

2

This error (and other like it) can occur when your development runtime and deployment environment have different versions of packages installed in the GAC and not all dlls from the development environment are copied into the deployment environment.

This question has guidance that might be useful: EntityFramework.SqlServer.dll not is getting added to the published folder only when I publish in RELEASE mode

  • My preferred workaround is to follow this advice and make a code reference to a class or function within each of the DLLs that you depend on to 'trick' visual studio into including the dll in the output by default AND to force a compile time error if that assembly is not available (useful in situations where the DLL is used via injection).

If you don't know which dll might be the cause and the app runs fine in development, then a simple fix can be to mark ALL references as Copy Local = True:

Copy Local True

Then if that works you can remove the DLLs from the output that you think you don't need, iteratively testing that the app still runs until you find the minimal set of dlls that you need to deploy

Chris Schaller
  • 13,704
  • 3
  • 43
  • 81