HDF.PInvoke icon indicating copy to clipboard operation
HDF.PInvoke copied to clipboard

Dotnet core fails loading native dlls

Open hpbieker opened this issue 7 years ago • 2 comments

When running a dotnet core 2.0 unit test that uses a netstandard 2.0 package that uses HDF.PInvoke, it fails with the following exception:

System.TypeInitializationException: The type initializer for 'HDF.PInvoke.H5F' threw an exception. ---> System.DllNotFoundException: Unable to load DLL 'hdf5.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)

HDF.PInvoke adds this to my PATH variable before loading the native dlls: C:\Users\XXX.nuget\packages\hdf.pinvoke\1.10.1\lib\bin64

However, the actual binaries are located in: C:\Users\nohabie.nuget\packages\hdf.pinvoke\1.10.1\build\bin64

Copying the native dlls to the build of the test "solves" the problem.

hpbieker avatar Dec 08 '17 07:12 hpbieker

Hi, currently I'm having the same Problem. I have a blank new project with HDF.PInvoke from the nuget Manager.

I copied the native Dlls itself and the bin64 folder in every directory of : C:\Users\XXX.nuget\packages\hdf.pinvoke\1.10.1\ and C:\Users\gruepazu\source\repos\ConsoleApp1\packages\HDF.PInvoke.1.10.1.0\ .

didn't help, still get the error of missing hdf5.dll

How did you found out what HDF.PInvoke adds this to your PATH environment Variable? Is this a bug or am I doing something wrong with the installation?

EDIT:

I accidently found out that the PInvoke.dll get's copied in the bin/Debug folder of the apllication. So desperatly i copied the native DLLs in there as well. That worked !!?!?! But why?? Why the Dlls are recognized at this place?

PvtSchneewitchen avatar Feb 09 '18 14:02 PvtSchneewitchen

Now (maybe with the patch of #142) this seems to work when targeting .NET 6, but still fails when targeting .NET Framework.

The native .dlls are correctly deployed to the ./bin64 directory, but the trouble is to find them there. In theory, there is a convenience method HDF.PInvoke.NativeDependencies.ResolvePathToExternalDependencies(), but this seems to have no effect when called in my library...

My final workaround was to copy'n'paste the implementation of this method and call it on the first best opportunity like so: https://github.com/ionicon-analytik/H52O/commit/bd863f9320e8d45cd5686592e58ae1c09a309512

lefi7z avatar Mar 22 '23 18:03 lefi7z