0

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?

Community
  • 1
  • 1
bonCodigo
  • 14,268
  • 1
  • 48
  • 91
  • 2
    what is the build type of the third party dll? is it x86 based? what is the error message you are getting? – Rezoan Apr 23 '15 at 06:32
  • 2
    You need to give more info: the exact error message, the tool involved, etc. – Patrick Hofman Apr 23 '15 at 06:33
  • Is "Can't find the third party .dll whenever build is Any PC" the error message you see in he build console? – Patrick Hofman Apr 23 '15 at 06:49
  • 2
    if you use a x86 based library on Any CPU build it wont work. make sure to use the library that matches with the build type of your application. – Rezoan Apr 23 '15 at 06:58
  • Check the installation requirement of your application satisfied the POS OS. anyway what kind of problem are showing on POS OS? – Rezoan Apr 23 '15 at 09:07
  • Can you please tell me the POS OS is x64 or x86 based? also show us some code sample that how you are importing the dll. – Rezoan Apr 23 '15 at 10:43
  • @x86. The .dll is imported via pinvoke. – bonCodigo Apr 23 '15 at 10:51

1 Answers1

0

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).

Paweł Mach
  • 705
  • 1
  • 11
  • 23
  • 1
    My bet is, as I said, on system architecture. Are you sure, that neither of the libraries are platform-specific? From the look on list of OSes, it would look like it works only on desktops. Consult library documentation for list of platforms supported. It may be dependant on system library, for example for GUI rendering or similiar task. – Paweł Mach Apr 23 '15 at 09:55
  • The application has few aspects. `1.` It has an application set up for user to change folder paths and passwords so on. `2.` the third party .dll is used to connect to another device. In terms of running the application it runs, GUI is pretty intact and when we click on connect to the device from POS, it throws the above error. So it's more or less not really a GUI rendering but directly on that .dll. I am also suspecting that POS has not completely clean up the old registry via control panel uninstall and it may be pointing at an older version. – bonCodigo Apr 23 '15 at 10:29