1

This question might be better asked with an example, so looking at the Confluent.Kafka NuGet package:

This package contains native dependencies (via librdkafka.redist) which, when when the package is installed in a consuming project, end up in subfolders of the project's output directory:

Project output directory subfolder containing the native dependencies

At runtime these assemblies are found, and from using Process Monitor it seems that they are found immediately (i.e. they do not fail to be found in other places first, following Windows' DLL search order, the application process goes directly to C:\Somewhere\NativeDependencyExample\bin\Debug\librdkafka\x64\librdkafka.dll).

When I look at the source code of Confluent.Kafka, I don't see anything special being done to resolve the native dependencies from this subfolder (the DllImport is just being done by module name, implying it has to be found using the normal DLL search order).

So does anyone know if there is some additional convention that the .NET Framework or Windows uses to resolve native dependencies like this? It's not simply the case that all subfolders are searched, because other native dependencies in other application subfolders do not get found this way. I'm also pretty sure I've seen other NuGet packages with native dependencies work in a similar way to Confluent.Kafka.

So is it because the librdkafka subfolder shares the same name as the module being loaded with DllImport? Is the resolving of the DLL in either the x64 or x86 folders also being done by convention? Is this documented somewhere?

Adam Goodwin
  • 3,951
  • 5
  • 28
  • 33
  • You can download [librdkafka.redist.1.5.0](https://www.nuget.org/packages/librdkafka.redist/) dependent package and manually examine a `build` folder inside it. There is a bunch of msbuild files, as well as C++ sources and native dependencies for windows, osx and linux. I believe this's a way how these files will come to your project – Pavel Anikhouski Oct 05 '20 at 14:45
  • I have done that, but it doesn't make it clear to me how these DLLs are being resolved at runtime. – Adam Goodwin Oct 05 '20 at 14:46
  • It almost looks like [side-by-side assemblies](https://learn.microsoft.com/en-us/windows/win32/sbscs/assembly-searching-sequence) could be something to do with it, but then this doesn't account for the x86/x64 subfolders: – Adam Goodwin Oct 05 '20 at 19:44

0 Answers0