We Keep Coding

64bit C# .Net Wrapper for 32bit C# .Net DLL

I have a 32bit Software written in C# who Communicates with many different devices.
Because of memory problems i upgraded to a 64bit System, no big Deal for the C# Software itself.
But for some of the implemented devices i had to change the way of implementation, it worked for all expect for one!
There i have a DLL which is written in C# 32bit, who is responsible for the communication to the device. Made by the supplier. I asked the supplier for a 64bit version but unfortunately its not possible for them to give me one.
My Idea was to create an Wrapper to make the DLL available to my 64bit Software.
I have seen that there are where many other people with a similar problem, but they always hat to Wrap an unmanaged DLL.
So my tried to write an wrapper who use COM to get the work done. But failed while implementing the C# COM Server into my C# Client. Here is the Idea what is tried:
https://blog.mattmags.com/2007/06/30/accessing-32-bit-dlls-from-64-bit-code/
Another Idea was to use a open source Project who can this topic with DLLImports:
https://github.com/CodefoundryDE/LegacyWrapper
There i could load it with DLLImport but i could not find the EntryPoint to my needed functions.
The question here is, if i'm completly on the wrong way and i can not load a managed DLL into C# with DLLImport or if i missed something and i just need to adjust the parameters.
Here is the Code i used so far (i changed the Names of the DLL)
[LegacyDllImport(#"C:\Program Files (x86)\Company\Device\API.dll")]
public interface IClassA : IDisposable
{
[LegacyDllMethod(CallingConvention = CallingConvention.Winapi)]
bool MethodA();
}

As addition to the #CyberMochi answer.
In particular case of x86-server and x64-client we don't need to call CoCreateInstance explicitly, as in case of bitness missmatch the standard .net COM interop mechanisms can do all the things automatically for us.
So, with the same sample (https://github.com/dotnet/samples/tree/main/core/extensions/OutOfProcCOM) I done the following:
(optional) Migrated to net6
Explicitly set bitnes for client (<PlatformTarget>x64</PlatformTarget>) and server (ExeServer.csproj: <PlatformTarget>x86</PlatformTarget>)
Built and registered server with "<path-to-samples>\ExeServer\bin\Debug\net6.0\ExeServer" /regserver (this need to be executed from elevated/admin command line)
Removed IServer declaration from the client project as the all information needed will be extracted from a tlb.
Reference the Server.Contract.tlb (from \ExeServer\bin\Debug\net6.0 folder) in the client project - "Add COM reference" into solution explorer. This added the following into csproj
<ItemGroup>
<COMReference Include="ServerLib">
<VersionMinor>0</VersionMinor>
<VersionMajor>0</VersionMajor>
<Guid>46f3feb2-121d-4830-aa22-0cda9ea90dc3</Guid>
<Lcid>0</Lcid>
<WrapperTool>tlbimp</WrapperTool>
<Isolated>false</Isolated>
<EmbedInteropTypes>true</EmbedInteropTypes>
</COMReference>
</ItemGroup>
Use the server from the client with the code
var server = new ServerLib.Server();
var pi = server.ComputePi();
Console.WriteLine(pi);
Some additional notes:
You can use per-user registration of the COM server. This will not require admin priveleges. But you will need to rewrite registration code - see here for details: Registering a COM without Admin rights
Instead of COM reference you can manually create COM interop DLL from the tlb with a tlbimp tool and reference this interop dll. This will speedup a build process.

I used the example: https://learn.microsoft.com/de-de/samples/dotnet/samples/out-of-process-com-server/
Here is the Git Link: https://github.com/dotnet/samples/tree/main/core/extensions/OutOfProcCOM
to create an out of process com server to handle the bitness difference.
i "only" had to get familiar with the concept and had to change the the call of the Server a bit. I changed the value of "CLSCTX_LOCAL_SERVER" from 0x4 to x40004 to force the call of a x86 Server!
private class Ole32
{
// https://docs.microsoft.com/windows/win32/api/wtypesbase/ne-wtypesbase-clsctx
public const int CLSCTX_LOCAL_SERVER = 0x40004;//0x4;
// https://docs.microsoft.com/windows/win32/api/combaseapi/nf-combaseapi-cocreateinstance
[DllImport(nameof(Ole32))]
public static extern int CoCreateInstance(
[In, MarshalAs(UnmanagedType.LPStruct)] Guid rclsid,
IntPtr pUnkOuter,
uint dwClsContext,
[In, MarshalAs(UnmanagedType.LPStruct)] Guid riid,
[MarshalAs(UnmanagedType.IUnknown)] out object ppv);
}

DLLImport is showing my current directory in another user machine

I am new to PInvoke, I wanted to update my system volume using C#, I got one C++ dll and I have to just Import that DLL and use the methods to update the volume.
In C# I have written :
public const String DllName = "ChangeVolumeWindows.dll";
[DllImport(DllName, CharSet = CharSet.Auto)]
public static extern void SetSystemVolume(double newVolume, VolumeUnit vUnit);
I have put my dll into the exe path.
It is working fine for my pc , but when I package the app and send it to another machine I getting error " DLL not found "
I have observed that DLLImport is looking for path of my pc, which is not correct
For example:
I have put my dll in C:/User/ABC/Source/App/bin/debug/ChangeVolumeWindows.dll
in some another machine also it is looking for the same path instead of taking dll from C:/User/AnotherMachineUser/Source/App/bin/debug/ChangeVolumeWindows.dll
Can some one suggest where my code is going wrong.
I have tried to put my dll inside the project and the rebuild. Still I am facing the same issue.

Try this:
My.Application.Info.DirectoryPath("\folders\ChangeVolumeWindows.dll")

Resolving native libraries inside WinRT package

Consider the following solution structure: Windows Store C# application + 2 native libraries PInvokeServer and PInvokeServer1. Native libraries code:
// PInvokeServer1
PINVOKESERVER1_API int TestFunction1(void)
{
return 5;
}
// PInvokeServer
PINVOKESERVER_API int TestFunction(void)
{
return TestFunction1();
}
Both functions are extern C. PInvokeServer depends on PInvokeServer1 (using linker dependencies). PInvokeServer.dll and PInvokeServer1.dll are added to C# project with build action Content, so they are part of the application package. C# declarations:
const string dllName = #"Native\PInvokeServer.dll";
const string dllName1 = #"Native\PInvokeServer1.dll";
[System.Runtime.InteropServices.DllImport(dllName, CallingConvention = CallingConvention.Cdecl)]
public static extern int TestFunction();
[System.Runtime.InteropServices.DllImport(dllName1, CallingConvention = CallingConvention.Cdecl)]
public static extern int TestFunction1();
Case 1, doesn't work (module not found):
TestFunction();
Case 2, works:
TestFunction1();
Case 3, works:
TestFunction1();
TestFunction();
Case 1: When PInvoke tries to load PInvokeServer.dll, it cannot resolve native runtime dependency, PInvokeServer1.dll is not loaded, and I get Module not found exception. Placing PInvokeServer1.dll, for example, to System32 directory doesn't help.
Case 2: PInvoke is able to load PInvokeServer1.dll directly.
Case 3. Once PInvokeServer1.dll is loaded, PInvokeServer.dll can be loaded successfully as well.
Im my real program I have native C library depending on several other libraries. All these libraries are added to C# Store application package. But high-level library cannot be loaded, because PInvoke fails to load dependencies. The only way I can think about is to load low-level libraries using LoadLibrary PInvoke call, and finally use PInvoke call to high-level library. Is there better way?

In a desktop application you could use AddDllDirectory or SetDllDirectory to modify the search path. But in a Windows Store application these functions are not available to you. So I see two options:
Put the two DLLs in the same directory as the executable. This is, by some distance, the simplest and safest solution. The executable's directory is always the first location searched and so you can be sure that the right DLLs will be loaded.
Before calling any function in either DLL, call LoadLibrary passing the absolute path to the DLLs to load them into the process. Load PInvokeServer1 before PInvokeServer. Change your p/invoke declarations to specify just the DLL filename. That is, remove the Native directory from the p/invoke declaration. By calling LoadLibrary explicitly, you make sure that the two DLLs are loaded into the process. Then subsequent calls to p/invoke functions will result in the already loaded DLLs being used.

Using 64-Bit SPSS Libraries in C#

I'm trying to create an .sav file programmatically without having to use SPSS automation (the SPSS.BackendAPI library) in order to free up more SPSS licenses. I found this library at CodePlex that uses the 32-bit I/O module without requiring a license, which is good.
The problem is that I need to build the application as x64 in order to gain access to the extra addressable memory in my own application. Thus, I need to use the 64-bit libraries as well. Has anyone had luck using the 64-bit libraries in managed code?

You can use that library from CodePlex, but you'll have to modify it a bit to work with the spssio64.dll that's included with the I/O Module. In the SpssThinWrapper.cs file, you'll need to change the DLL that's being imported. You'll also have to change some of the entry points. To get the names of the entry points in the 64-bit DLL, you'll want to run dumpbin /exports spssio64.dll. If you do this you'll see that the the 64-bit and 32-bit entry points are basically the same, except that some of the 32-bit ones have an # sign and a number after them, whereas none of the 64-bit entry points do. Do change all of those along with the DLL in the DllImport attribute. For example:
[DllImport("spssio32.dll", EntryPoint="spssCloseAppend#4", CharSet=CharSet.Ansi, SetLastError=true, ExactSpelling=true)]
public static extern ReturnCode spssCloseAppend(int handle);
becomes
[DllImport("spssio64.dll", EntryPoint = "spssCloseAppend", CharSet = CharSet.Ansi, SetLastError = true, ExactSpelling = true)]
public static extern ReturnCode spssCloseAppend(int handle);
and so on.
After doing this you'll want to make sure you're using the correct DLLs. Copy the spssio64.dll, icudt32.dll, icuin32.dll, and icuuc32.dll from the win64 folder of the I/O Module into the Resources folder from the SPSS .NET library from CodePlex. This will overwrite the existing 32-bit dlls, so if you need both 32-bit and 64-bit you'll have to do something different, but it sounds like you just need 64-bit, so this should work.
As an example of how easy it is to create an .sav with this library:
using (SpssDataDocument spssDoc = SpssDataDocument.Create("test.sav")) {
SpssVariable v = new SpssNumericVariable();
v.Name = "gender";
v.Label = "What is your gender?";
v.ValueLabels.Add(1, "Male");
v.ValueLabels.Add(2, "Female");
doc.Variables.Add(v);
doc.CommitDictionary();
SpssCase c = doc.Cases.New();
c["gender"] = 1;
c.Commit();
}
The library handles all of the spss* calls for you, and makes sure they're in the right order and everything.

Why don't you just use the SPSS Statistics i/o dll available via the SPSS Community site (www.ibm.com/developerworks/spssdevcentral)? It is free and comes in 32 and 64 bit versions for all the supported SPSS platforms. It does not require an SPSS license.

c# dllimport of MsiGetShortcutTarget(msi.dll) failed with error 1603 under Windows 7

I want to resolve an advertised MSI shortcut in c# as described here:
How to parse "special" .lnk files, aka. MSI shortcuts aka. Windows Installer advertised shortcuts using C#
[DllImport("msi.dll", CharSet = CharSet.Auto)]
private static extern UInt32 MsiGetShortcutTarget(
string szShortcutTarget,
[Out] StringBuilder szProductCode,
[Out] StringBuilder szFeatureId,
[Out] StringBuilder szComponentCode);
public static string ParseShortcut(string file)
{
StringBuilder product = new StringBuilder(MaxGuidLength + 1);
StringBuilder feature = new StringBuilder(MaxFeatureLength + 1);
StringBuilder component = new StringBuilder(MaxGuidLength + 1);
UInt32 res = MsiGetShortcutTarget(file, product, feature, component);
...
}
I use VS 2010 and tried with different settings for "Platform target" and/or "Target framework". MsiGetShortcutTarget always returns 1603 (A fatal error occurred during installation) under Windows 7.
I tried to do the same with c++ and I can resolve the Shortcut and everything is fine. I also tested with a msi.dll, that I copied from a Windows XP and this dll can resolve the Shortcut with the C# code. I have no idea why the c# code won't work with the msi.dll under Windows 7.
I testet MsiGetComponentPath with a known product GUID and component GUID to resolve the target path in c# with the dll, that returns 1603 for MsiGetShortcutTarget and it works perfectly. So only MsiGetComponentPath fails under Windows 7 and I don't know why it went wrong.

This seems related to the way COM is initialized.
If I add [STAThread] to my Main method, it works fine (well, if you actually use StringBuilder instead of char[] for your arguments :-), but I get a return value of 1603 when using MTA.

I highly suggest taking a look at WiX's Deployment Tools Foundation. It has a really nice interop library developed by a MSFT employee that makes calling MSI easy.
For example, the Microsoft.Deployment.WindowsInstaller namespace has an Installer class that exposes a static method ShortcutTarget GetShortcutTarget( string shortcut ). The ShortcutTarget class then has get accessors for ComponentCode, Feature and ProductCode.
Additionalyl this is an open source project so if you really, really want to know how the P/Invoke stuff works you can look at the code.