I was wonder if it is possible to NuGet GDAL for use in a .NET Addin module?
I got the recommended GDAL 3.5.0 and GDAL.Native 3.5.0 NuGet libraries via Visual Studio 2022 and everything came in fine. However, when running the required GdalConfiguration.ConfigureGdal() command, I get an exception: "The type initializer for 'OSGeo.GDAL.GdalPINVOKE' threw an exception."
I've looked around and there's not a heap of information on it. If I create a new C# project without ArcGIS SDK I can use GDAL without any issues, so I am assuming this is a ArcGIS Pro conflict?
@LewisTrotter I'm using GDAL 3.4.1 in conjunction with an Add-In I've developed but I'm not using it directly from C#. I've statically linked it to another C++ library that I am calling from C#. I do this via a SWIG generated interface. Nonetheless the PINVOKE exception is the key to your problem. PINVOKE is a method by which C# code can call C++ code. But that C++ code has to be in a DLL. Last time I checked ArcGIS Pro SDK does not see native dependencies (i.e. on C++ DLLs) and will not copy your DLL to the appropriate C:\Users\<user-name>\AppData\Local\ESRI\ArcGISPro\AssemblyCache folder at run time so your code is trying to load a DLL that is not there. In my case, we decided to use our AddIn Module code to copy all Native DLLs to that directory when the plugin loads. This is because an assembly will search a specific series of directories for a DLL (https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order) and the current directory of the calling process is one of them. A simple check, that requires no code changes, is to put the GDAL 3.5.0 DLL into one of the directory's in your PATH and try again. Good luck!
@CharlesMacleod Thanks! I'm going to be moving my AddIns to 3.0 soon but hadn't looked at what that would entail yet and you're URL gave me a heads up on some things that have changed that I'll need to factor into that work. Specifically that the Add-In Content approach has gone away...
As for libraries referenced in your Add-in make sure that you set the 'Copy Local' to yes for that library file:
This should ensure that the dll is copied into the add-in's executable folder. Having not used GDAL, I would suggest following the debugging steps suggested by @DHuantes
