Search code examples
c#winformsvisual-studio-201532-bitanycpu

How to handle C# Third Party DLLs with Any CPU & Prefer 32-bit?


My application is built on "Any CPU" as the platform. It requires two, third-party DLLs.

For DLL #1, I must not check "prefer 32-bit" in my Build Settings in order to use it.

For DLL #2, I must check "prefer 32-bit" in order to use it.

How can I resolve this?

Both DLLs are useable in an "any CPU" application - just not at the same time.

If I switch to an x86 platform, DLL #1 will not work at all.

Thanks


Solution

  • So, you have 32-bit unmanaged dll (let's name it unmanaged32.dll) and managed 64 bit dll (managed64.dll).

    Obviously both of them can't work in the same process under the any circumstances.

    The best way to handle this is to find or build a version of one of the dlls for the other bitness, i.e. 64 bit version of unmanaged32.dll or 32-bit version of managed64.dll. After this you will have both dependencies of the same bitness and just need to configure build of your app to this bitness.

    If it's impossible to get all dependencies of the same bitness, then the only way is to move out one of the dependency to the separate process of another bitness and work with it over some kind of IPC, e.g.

    • main app + unmanaged32.dll in the 32-bit process and managed64.dll in the separate 64-bit process.
    • main app + managed64.dll in the 64-bit process and unmanaged32.dll in the separate 32-bit process.

    Which dependency to move out is up to you and depends of the functionality/API of each dlls.

    If you will decide to move out a unmanaged32.dll you can try to use LegacyWrapper package (https://github.com/CodefoundryDE/LegacyWrapper) which can do all things for you. Have not tried it myself, but hear good about it.

    I did not know ready-to-use solution for moving out the managed dll (managed64.dll), so you will need to implement this manually if you decide to go this way. See sample here: 64bit C# .Net Wrapper for 32bit C# .Net DLL (and check both answers, not only first one)

    You can also implement such a wrapper for unmanaged dll too in case of LegacyWrapper will not fit your needs.