What is the reason that FTD2XX functions do not work in VB.NET after Visual Studio update(?), is the-CodePudding

I am developing an app in VB.NET (for a customer with hardware using FTDI USB serial chip. Communication uses FTD2XX library and the respective Nuget package (FTD2XX.Net v1.2.1). After some update of Visual Studio (probably update to 17.1, but I am not sure) all functions except a few stopped working. Current VS version is 17.1.1. For instance, it is possible to obtain number of devices attached by the FTDI driver:

Friend Declare Function FT_CreateDeviceInfoList Lib "FTD2XX.DLL" (ByRef lngNumDevs As Integer) As Integer
...
Dim ftStatus As Integer
Dim numDevices As Integer
ftStatus = FT_CreateDeviceInfoList(numDevices)

In the above snippet ftStatus result = 0 (i.e. OK) and numDevices is set to 1 (correct).

Problem starts when I want to do something serious:

Friend Declare Function FT_GetComPortNumber Lib "FTD2XX.DLL" (ByVal lnghandle As Integer, ByRef lplComPortNumber As Integer) As Integer
Friend Declare Function FT_Open Lib "FTD2XX.DLL" (ByVal iDevice As Integer, ByRef lnghandle As Integer) As Integer
Friend Declare Function FT_Close Lib "FTD2XX.DLL" (ByVal lnghandle As Integer) As Integer
Dim portHandle as Integer
Dim cpNumber as Long
For i% = 0 To 255
   ftStatus = FT_Open(i, portHandle)
   If ftStatus = FT_OK Then
      ftStatus = FT_GetComPortNumber(portHandle, cpNumber)
      ftStatus = FT_Close(portHandle)
      ' here is some non-essential code registering that port at index i% exists...
   End If
Next

In the above code, FT_Open returns ftStatus = 0 (FT_OK) and sets a value for portHandle.

However, the next call, FT_GetComPortNumber, returns ftStatus = 1 (FT_INVALID_HANDLE) and the value passed to cpNumber is 0xFFFF (shows as positive, but in fact should be -1, I guess...). What is worse, FT_Close() also returns FT_INVALID_HANDLE and the port remains open. I verified it by trying to open the port from another app - access denied.

Sometimes it seems that FT_Write and FT_Read functions work despite this mess, but in my last try I could not any communication with the hardware at all.

I tried to use System.IO.Ports.SerialPort as possible workaround but that does not work at all. On top of that, I need to use bit-bang on RTS, because it controls supply voltage and reset of the hardware connected to the other side of the FTDI chip. Without possibility to bring RTS down for hundreds of milliseconds and then hold it up all the time I cannot control the hardware. AFAIK System.IO.Ports.SerialPort provides no possibility to do that.

What could be the solution?

CodePudding user response：

After much trial and error, it appears to be a problem in compile configuration. Open Solution properties Window and click on the Compile tab.

Then click on "Advanced Compile Options"

If the "Remove integer overflow checks" checkbox is not checked, check it!

I have no idea how an integer overflow check can garble a 32-bit number not involved in any arithmetic operation whatsoever, but this is what really happened. I consider this a bug in Visual Basic compiler used in Visual Studio 17.1.6 (and a number of previous versions), but I did not dig deeper in this topic.

CodePudding user response：

@HansPassant writes:

The declarations are wrong, it must be lnghandle As IntPtr. The difference between Integer and IntPtr matter when you run the app in 64-bit mode. Prone to happen when targeting .NETCore, as likely in VS2022.

-- Hans Passant