Not clear if native dlls are possible

Question

Not clear if native dlls are possible

Closed this issue 9 years ago · 6 comments

The docs suggest native dlls are possible but may need one of the scenarios to be used. I've tried a simple test and it fails:

.\packages\LibZ.Tool\tools\libz.exe inject-dll -a .\Debug\Analytics.dll -i .\lib\MKL\x86\libiomp5md.dll --move

which results in the following:

LibZ 1.2.0.0, Copyright (c) 2013-2014, Milosz Krajewski
https://libz.codeplex.com/

Executing inject-dll (Injects .dll file into assembly as resource):

Loading '.\Debug\Analytics.dll'
Loaded 'Analytics, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'
Loading '..\lib\MKL\x86\libiomp5md.dll'
Failed to load assembly from '..\lib\MKL\x86\libiomp5md.dll'
Assembly '..\lib\MKL\x86\libiomp5md.dll' could not be loaded
No files injected: .\lib\MKL\x86\libiomp5md.dll

I've looked at the source for the error message but am confused as to if a native dll are supported.
Am I missing something?

Many Thanks

Answer 1 · 2015-11-17T21:59:41.000Z

Please point me to the sentence which might suggest it works with native dlls. It absolutely doesn't and if there is anything ambiguous I would like to make it clear.

If you are referring to this:
"VidCoder has two native assemblies: hb.dll and System.Data.SQLite.dll. There is a funny thing with SQLite assembly. It seems to be managed assembly but it P/Invokes itself so it requires to be physically in application folder. Strange. Why it wasn't done as mixed mode? I don't know. Anyway it cannot be embedded." please note, that I'm just describing the case of "System.Data.SQLite.dll" which looks like managed dll (so might be embedded) but it isn't therefore it cannot.

Answer 2 · 2015-11-25T21:56:15.000Z

It was this bit in the reason for building the library:

I was porting come code from C/C++ to .NET. I wanted native implementation for desktop and safe implementation when running in restricted environment. This lead to the situation where I had 6 assemblies doing exactly the same thing: native-x86, native-x64, c++/cli-x86, c++/cli-x64, c#-unsafe-anycpu, c#-safe-anycpu and one additional assembly which was a façade which was redirecting all the calls to fastest one (depending on platform and trust level). I just didn't like 7 assemblies polluting executable folder. With LibZ I was able to embed all of them in the façade and distribute it as single file, handling all platforms and trust levels.

Answer 3 · 2015-11-26T08:24:34.000Z

Yup. You are right. It actually was mixed-mode not native. I'll fix it. Thanks.

Answer 4 · 2016-04-14T20:31:03.000Z

Update documentation: 4b14dd3

Answer 5 · 2016-09-20T20:21:32.000Z

So therefore the native ones have to remain un-embedded ? What if we mark them as "Embedded resource" when building ? Can they be found by a dll that was embedded with LibZ ?
Sorry if I'm asking something stupid, I'm really new to this.

Answer 6 · 2016-11-06T18:01:53.000Z

README.md ends with the paragraph, "Please note that this approach works for trivial applications only. If your application (or 3rd party libraries) use reflection, application domains, native DLLs you might need more "personalised" approach. Please refer to Scenarios." emphasis on native DLLs, this still suggests that LibZ (at least to me) that it is possible to use this tool with native libraries.

It was this issue where you commented, "It absolutely doesn't and if there is anything ambiguous I would like to make it clear." that tipped me off - so I'm commenting to let you know that the last paragraph of README.md to me, still reads ambiguously.

Cheers