andreyakinshin / interopdotnet Goto Github PK

Interesting project. Thanks!
Can you publish nuget package?

The current implementation is not very suitable for the case when the native library is dependent on other native libraries.

What do you think about the following options use native libraries?

1. Before loading of libraries depending on the environment (Mono \ x86, Win \ x64 ...) set the variable Path or call function SetDllDirectory
2. Access the libraries using standart DllImport attribute (without a path parameter).

Can't believe I am the first to comment on this project. I have several dot.net projects I want to run on mono and this code seems to get me a long way to get there. I was impressed it was used to solve mono compatibility with the tesseract project.

Anyway it compiles but when I run I get this error.

The program can't start because MSVCR120D.dll is missing from your
computer. Try reinstalling the program to fix this problem.

Doing my due diligence googling I found that dll is for debugging in 2013 and not part of the runtime distribution package so I can't get it on my machine. No one without vs 2013 would be able to run it? I figured I could solve the error by compiling the native dll in 2012. Needed to do that anyhow since there was no dll to test again. Still getting the error.

I am a little perplexed with where it is getting the reference to vs 2013 debug.

Hello
Usually when creating wrapper classes for unmanaged code it is assumed, that classes will be internal (we do so). But you library requres interface with DynamicDllImport attributes to be public.

What do you think about to create new attribute and apply it to interface. This attribute will be used to discover and implement public, internal and private interfaces

Hi,
I've done, in other interop project(s), some of the same things that you do in this project (namely Preloading with dlopen / LoadLibrary)
The one main difference (Except for your approch being generic and published on NuGet of course... 👍 ) is that still kept on using the "normal" [DllImport] attributes with the additional [SuppressUnmanagedCodeSecurity] attributes to eliminate much of the standard P/Invoke ovearhead..

Does you approach actually reduce/increase the overhead (of the runtime, naturally, not the initialization) when compared to P/Invoke?

• related to charlesw/tesseract#563
• having issues using the createinstance inside of a publish single exe dotnet core 3