Search code examples
c#dllbuild-processx86-64

Application builds yet execution fails on Any CPU build


So there are couple of questions asked on this matter. There's x86, x64 secondary project that references another project created on x86 and based on a third party .dll built on x86.

The entire DLLImport and marshal call com wrapper was created using an upgrader tool. It upgraded VB6.0 into .Net code. The final .exe is installed and run in every PC as long as it is released using a x86 build. But it fails when build is on AnyCPU configuration.

When AnyCPU build is done and programme is executed the code keeps throwing an error on third party .dll and complaints it can't find the .dll. None of these issues persists when build is on x86. This is a practical issue as the application is meant for a device on Windows Embedded Standard OS and most Windows OSs from Windows XP onwards.

Error :

System.DllNotFoundException was unhandled  HResult=-2146233052
  Message=Unable to load DLL 'posLTD.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)
  Source=ProjectOne      TypeName=""      StackTrace:
       at PorjectOne.PInvoke.UnsafeNative.POSLTD.ConnectToDevice(Int32 nMachineNo, String& strIpAddress, Int32 nNetPort, Int32 nTimeOut, Int32 nProtocolType, Int32 nNetPassword, Int32 nLicense)

What can be done to solve this? Could this be the device OS compatibility issue?


Solution

  • Some of the third party libraries are created in such way, that they can not be compiled for any other architecture.

    For example, at least theoretically you could use exactly same part of code in x86, x86_64 and ARM(eg. Universal App), if you wrote it from scratch using .NET. But if the library is compiled only for x86(be it bad will of developer or optimalization), it can only be used by applications with same architecture. A fine example of this is SQLite, which is a pain in the back for any Windows Phone 8 developer - you must have both x86 for debug in emulator and ARM for production(AFAIK, at least we never found a way to have only one).