Here is c++ dll code:
#include<stdlib.h>
#include "pch.h"
extern "C" _declspec(dllexport) int Add(int a, int b)
{
return a + b;
}
C# code, that i run in Visual Studio:
[DllImport(@"C:\Dll1.dll", CharSet = CharSet.Ansi, CallingConvention = CallingConvention.Cdecl)]
public static extern int Add(int port, int speed);
public static void Main()
{
int res = Add(8, 11);
Console.WriteLine(res);
}
No problems, output: 19
PowerShell code:
Add-Type -Name MyFunctions -Namespace Cpp @'
[DllImport(@"C:\Dll1.dll", CharSet = CharSet.Ansi, CallingConvention = CallingConvention.Cdecl)]
public static extern int Add(int port, int speed);
'@
[Cpp.MyFunctions]::Add(8, 11)
Output:
An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)
But functions from user32.dll/kernel32.dll imports without any problems.
How to fix it?
Make sure that you are using 32 bit dll for 32 bit powershell process and 64 bit dll for 64 bit powershell process. The error looks like as if you trying to load 32 bit dll into 64 bit process. Please note that .net applications compiled as "Any CPU" will run in 32 bit mode by default even on 64-bit operating system.
Update
If you have a sources for your dll, then you should recompile it for 64 bit environment and then import this 64-bit build.
If you need to execute PS script in a both 32- and 64-bit powerShell environments, then you should deploy two versions of dll and select the right one in runtime. I do not know how this can be done for PS, but for C# solution you can use #ifdef-based solution as described here: Using a 32bit or 64bit dll in C# DllImport
If you do not have sources for your dll, then all become complicated and I do not know any direct solution here. You can try to wrap your DLL in the 32-bit in-process (or even out-of-process) COM server (with help of C# or C++) and then use this server with New-Object. As I know, the Windows have special shims which allow to utilize 32-bit COM objects from 64-bit process and vice versa, but I am unsure if this will work for PS or not.
For build-in DLLs Windows has automatic file paths redirection from System32 to SysWOW64. So, when you requesting user32 import, you will get different user32 libraries depending on your process bitness. You can read more about this here: 64bit PowerShell calls the 32bit DLL