in reply to Re^3: Import a DLL from C# to Perl
in thread Import a DLL from C# to Perl

And, AFAIK, it doesn't matter whether the dll you want to load was built from C code or C# code or C++ code.

There is a problem with C#, in as much as (AFAIK) it always produces .NET Managed Assemblies. Essentially, the DLL contains initialisation and thunking code to connect it to the .NET subsytems, that needs to be called for stuff to work. It's meant to be done by wrapping it in a COM wrapper; but there is another way: Reverse P/Invoke

At that point, I've described more than I understand, so I'll leave it to the OP to follow the link and read about there.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority". The enemy of (IT) success is complexity.
In the absence of evidence, opinion is indistinguishable from prejudice. Suck that fhit

Replies are listed 'Best First'.
Re^5: Import a DLL from C# to Perl
by syphilis (Archbishop) on May 10, 2018 at 04:56 UTC
    ... the DLL contains initialisation and thunking code to connect it to the .NET subsytems, that needs to be called for stuff to work

    I can't claim to have any knowledge about C#, but I think that paulorfmmb has indicated that he can access his C#-built dll from C code (presumably using his MS C compiler to build the C executable).
    I was thinking that if the same dll cannot be accessed by an executable built from the same C code, but built with a gcc (mingw-w64) compiler, then it's because of a difference in the environment under which the gcc-built executable is running.
    If that's so, then it's just a matter of fixing the environment when running the gcc-built executable.

    However, I guess it's also possible that building the executable with a Microsoft compiler does stuff that doesn't get done when building with gcc - and that this explains the failure of gcc-built apps to deliver.

    Or, FAIRK, maybe the problem is something entirely different again.

    Cheers,
    Rob
[reply]
      I guess it's also possible that building the executable with a Microsoft compiler does stuff that doesn't get done when building with gcc

      If he's building stuff using the VS GUI,or one of the XML build files it generates; it likely doing a crap load of stuff that he hasn't explicitly asked for.

      (eg. I think if you ask VS to link a C program to a C# dll, it knows to add (unseen) code to initialise the .NET runtime. (*I think*))

      That said, I don't use gcc, so maybe that knows how to do all that stuff (now).

      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority". The enemy of (IT) success is complexity.
      In the absence of evidence, opinion is indistinguishable from prejudice. Suck that fhit
[reply]

In Section Seekers of Perl Wisdom