6

I am trying to compile the example project shown here for C#. It had to be converted to VS2010, but that worked fine. It builds, runs, but then dies when it tries to access a DLL function.

I made a series of images to show my steps. As you can see, the device I designed is attached and correctly configured, but I really don't think that has anything to do with the issue. Inside the Form1.cs file, the following comment explains how to use the DLL:

/*
PLEASE NOTE
You must add a reference to the FTChipIDNet.dll in order to use this sample
To do this:
1. Click on Solution explorer tab.
2. Right click the References tree.
3. Choose Add Reference option.
4. Browse to the FTChipIDNet.dll (as a personal preference I place this in my bin directory)
5. Click OK
*/

I followed the instructions shown above and the undefined reference to the namespace FTChipID was fixed. I also manually checked the Object Browser to be sure the GetNumDevices function exists and it does.

Clicking the button produces this error:

DLLNotFoundException was unhandled:

Unable to load DLL 'FTChipID.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)

at this line of code:

FTChipID.ChipID.GetNumDevices(ref numDevices);

Now, you may be thinking "the error says it needs FTChipID.dll, not FTChipIDNet.dll." I'm wondering the same thing. I have FTChipID.dll along with a .lib and .h file, but I don't know how to use them or where they need to be in order for this program to find them. I tried adding a reference to FTChipID.dll, but VS2010 said

A reference to ...\FTChipID.dll could not be added. Please make sure that the file is accessible, and that it is a valid assembly or COM component.

I don't know what that means either. Any ideas? Thanks in advance.

Community
  • 1
  • 1
Anthony
  • 1,760
  • 1
  • 23
  • 43
  • are you adding the .dll as part of the project reference..? aslo are you consuming the namespace of that .dll.. also look into versioning of that .dll.. or GAC if necessary if the .dll is a .net 2.0 - 3.5 .dll vs a .net 4.0 .dll also take a look at the property settings for the project make sure it's a 4.0 project I would also try to compile it as a 3.5 project as well to see what the differences are.. – MethodMan Dec 27 '11 at 18:27
  • Add FTChipID.dll as an output in your project (or copy it to the bin\Debug folder) and retry. I guess the FTChipIDNet.dll is a wrapper for the former. – rene Dec 27 '11 at 18:31
  • Put the FTChipID.dll in the same directory as FTChipIDNET.dll. The framework should be able to locate it then. – M.Babcock Dec 27 '11 at 18:33
  • Add the DLL to your project with Project + Add Existing Item. Set its Copy to Output Directory property to "Copy if newer". – Hans Passant Dec 27 '11 at 18:46
  • I copied FTChipID.dll into the bin\Debug folder. It produces some weird behaviors. Running the debugger inside VS does the same thing - it can't find FTChipID.dll. Running the executable outside of VS2010 in the bin\Debug folder, however, produces a new error. "An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)." – Anthony Dec 27 '11 at 18:58
  • Oh yeah, I forgot to say that changing to framework version 3, 3.5, and 4 produced no differences in behavior before and after adding FTChipID.dll to the project and bin\Debug folder. – Anthony Dec 27 '11 at 19:04

3 Answers3

2

I built the FTDI sample program "CSChipID" in VS2013 using a build to "Any CPU". The two DLL files "FTChipID.dll" and "FTChipIDNet.dll" were copied to the bin directory, but I continued to get errors when the first DLL function was called, "FTChipID.ChipID.GetNumDevices(ref numDevices);" The fix is change the build to "x86" as follows.

Build - Configuration Manager Active Solution Platform - "x86" Note: If "x86" is not available, select -New...- to select "x86".

Lawrence Miller
  • 21
  • 1
  • yep thanks, this was the cause of my problem too, I had a debug build of my .net program. it worked when I rebuilt in visual studio x86 and Release configuration. It must be some sort of issue with the visual studio compiler. Not an issue with the dll, because I already had FTchip.dll in my c:\windows\ folder, and it had already been working prior. – hamish Nov 25 '15 at 07:31
2

FTChipIDNet.dll is a wrapper for the FTChipID.dll, so you need to add the reference to your solution (as you did above) and then copy the FTChipID.dll to the bin folder there FTChipIDNet.dll will be located.

Both dll's should be located in your solution's bin folder to operate and should not be located in windows\system32.

Leons
  • 2,679
  • 1
  • 21
  • 25
  • Thanks. This at least produced a different error. After adding FTChipID.dll to the project as an existing item, VS2010 was able to find it while running the debugger. The new error is in the comment below my OP. – Anthony Dec 27 '11 at 19:00
  • Here is a link that might help with the new error message. http://stackoverflow.com/questions/2023766/an-attempt-was-made-to-load-a-program-with-an-incorrect-format-even-when-the-p – Leons Dec 27 '11 at 19:12
  • Thanks for the link. Reading that link prompted me to ask FTDI if they released a 64 bit version of FTChipID.dll. In less than 20 minutes, I got a response! "We do not currently offer a 64-bit version of the FTChipID.dll. We have users who compile for a 32-bit output and are told that runs well on both 32- and 64-bit systems." So, it looks like I have to use a 32 bit build. VS2010 Express doesn't offer that as an option, but I'll figure that part out. Thanks everyone! – Anthony Dec 27 '11 at 19:48
  • 2
    @Anthony: In Project Properties, change the `Target Framework` to 32-bit x86. – SLaks Dec 27 '11 at 21:28
0

It sounds like there are multiple .dll's: both FTChipIDNet.dll (the one you interface to), and FTChipID.dll (the one with the actual, non-COM, non-.Net functionality). You need both.

SUGGESTION: Copy both to your \windows\system32 directory

paulsm4
  • 114,292
  • 17
  • 138
  • 190
  • do you mean have him GAC both or copy both..? just curious about your response. – MethodMan Dec 27 '11 at 18:32
  • 3
    Application files rarely belong in the System32 directory. – M.Babcock Dec 27 '11 at 18:32
  • Yes this one DOES belong in the system32 folder, probably because its a related part of a driver system. Please keep it there as per original FTDI driver design. C:\windows\System32\FTChipID.dll I say this because his neighbour dlls are also there C:\windows\System32\ftd2xx.dll – hamish Nov 25 '15 at 07:34