question

tamasoz-8112 avatar image
0 Votes"
tamasoz-8112 asked tamasoz-8112 edited

NativeAssemblies loading issues with SqlServerTypes

Hi,

We are in the process of migrating a monolithic set of applications from a IIS/Windows server environment to Azure Webapps. Whilst we have faced significant challenges at many aspects of this migration project yet we still managed to find a decent solution for all matters.

However, this one doesn't seem to be working despite several tries.

As far as I understand on the legacy server environment, the SqlServerTypes were installed on Windows (applications work with spatial data in the SQL server). The application itself is composed of various smaller Class library projects and after migrating from the legacy server environment I installed the SqlServerTypes successfully with Nuget (there is one version available there, 14.0 or something). I followed up the library's readme's requirements to load the DLL's.

The required assembly loading routine is added to the Global.asax application start section - it loads in fine, during debugging I can see the Spatial library is loaded in and the system is working ok via the web application as well as via the subsequent class library dll's.

However, now we need to do the same with console applications. The Microsot.SqlServer.Types nuget is added to the console app and the necessary call to load in the library is added like this...

         static void Main(string[] args)
         {
             SqlServerTypes.Utilities.LoadNativeAssemblies(AppDomain.CurrentDomain.BaseDirectory);

Regrettably the system does not behave the same way how it does with the web application. I have debugged the application and stepped through the routine through the nitty gritty of Loader.cs. There is no exception thrown and the loading process is seemingly going through fine. Yet there are no Spatial library loaded in and upon calling the SQL table with spatial columns it keeps bellying up.

I checked all paths in the Loader.cs and they are all correct, everything is where it should be. There is a call where the logic should say something if the load is not happening:

   var ptr = LoadLibrary(path);
             if (ptr == IntPtr.Zero)
             {
                 throw new Exception(string.Format(
                     "Error loading {0} (ErrorCode: {1})",
                     assemblyName,
                     Marshal.GetLastWin32Error()));
             }

...but in my case the ptr is not IntPtr.Zero but something else.

I tried build/deploy on both 64 and 32 bit architecture. It is just not getting it.

The odd thing is that with web application - it all seems working fine.

I tried finding solutions on forums but I couldn't.

Well - any help will be appreciated.

Thanks

dotnet-standard
· 4
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

Completed some more testing regarding this issue and I can confirm the following:

1.
Using a Web Application (.NET Framework 4.8) and SqlServerTypes does work how it should. I created a blank solution, added the Nuget reference then the assembly loading routine to Global.asax Application_begin section. Debugged the logic and I saw this:


258943-msvcr120.png

258878-sqlserverspatial.png


...and in the Debug -> Module window I was able to see the Spatial DLL to load in fine:

258918-loadeddll.png


  1. These are the printouts of basic Console Application"

258981-msvcr120.png
258866-sqlserverspatial140.png

...and in the Debug -> Module window I cannot see the Spatial DLL:

258982-loadeddll.png


Not sure where to go from here to be honest. These Console applications must be able to read spatial columns from a SQL server database.

The Dev environment runs on an Azure VM (Server 2019, version 1809 - updated automatically), .NET 4.8.03761 framework with VS 2022 17.2.4. Nuget Microsoft.SQLServer.Types 14.0.1016.290 (this is the only version there).

0 Votes 0 ·
msvcr120.png (8.2 KiB)
loadeddll.png (15.1 KiB)
msvcr120.png (11.1 KiB)
loadeddll.png (16.1 KiB)

Addendum: I can now see the old Microsot.SqlServer.Types packages on Nuget, so tried them out all. Anything above version 11 is presenting the same issues as the lates. The version 10.50.1600.1 seems working - my test harness does not throw exceptions when encountering spatial columns as a result of the executed SQL procedure.

I will carry on additional testing with this version shortly to confirm that this is working - but so far it didn't seem to be throwing exceptions when encountering a spatial data.

0 Votes 0 ·

@tamasoz-8112, are you running your console app as a continuous webjob? What errors are you seeing from the web app?

0 Votes 0 ·

Well it is a console app. I can run it both on local environment or in Webjob - I got the same error.

DataReader.GetFieldType(16) returned null. It is not null but a spatial value.

Regardless - the issue is that the necessary DLL is not loading in despite all efforts. It does load in ok in Web Application.

Pretty much explained the case with the most accurate details previously along with debug printouts. The reason Im getting this error because the DLL doesn't want to load in in Desktop/Console apps despite running the necessary commands - again see example above.

0 Votes 0 ·

0 Answers