VM167 - Visual Basic 2008 Express

I have recently received this interface board, and successfully loaded the drivers on to my Windows 10 laptop using the SDK. The demo program runs as expected. However, I have put together a small Visual Basic program, using the DLL library calls in the pdf document, but on running the program in debug mode, at the first call to a DLL function Open() an exception is generated with the following message:
“An attempt to load a program with an incorrect format Exception HRESULT: 0x8007000B”. I have tried placing the VM167.DLL in alternative locations, e.g SysWOW64 and System32, as well as placing a copy in the project folder, but the behavour is unchanged.
It seems to me that Visual Basic 2008 Express does not like the VM167.DLL file that has been supplied as a download from your site. I would be greatful for some indication of how the get the routines in this DLL rcognised by Visual Basic
Many thanks,
Ian

It seems the issue is that VB 2008 is building the project to compile on “Any CPU” and the DLL is intended for x86 systems only.
Your project needs to be compiled for x86 systems only.
Please do the following to resolve the issue:
In the Tools --> Options --> Projects and Solutions–>General Check “Show advanced build configurations”
Select Tools --> Settings --> Expert Settings to see the Build option
In the Build menu click Configuration Manager…
In the Active solution platform select New…
Select x86 from the first ComboBox
Click OK

Good Morning Support Team,
I thank you for taking time to consider the problem I outlined a couple of days ago. You have identified correctly the source of the problem, and I have managed to configure the build for x86 systems, and I am pleased to report I can now interact with the VM167 card in the manner I had hoped for. However, I was not able to implement the fix exactly as you outlined; After implementing the first line, I was unable to find the Settings/Expert Setting in the Build Option. Some other online correspondent suggested that a project needed to have been loaded to get access to the build menu, and this helped me to add the x86 configuration.
It occurs to me that this point could be included in your PDF for the DLL - say, in the same section that you warn users that the DLL is not accessible from the Visual Studio environment? Additionally, would it be possible to issue your DLL’s that would in fact operate correctly for a development being carried out in a Visual Studio environment, since this is the standard for today’s developers?
Many thanks again for pointing me to a solution to my difficulty,
Regards,
Ian.

Thank you for the feedback.
Glad you resolved the issue.

Sorry, my mistake. - The option to choose Expert Settings / Basic Settings is only in VB 2010.

The current VM167.DLL works fine in a Visual Studio environment.
Please see the example projects how DLL calls are made

And please note the following:

  1. The VM167.DLL is a 32-bit Windows DLL.
  2. The main application must be compiled to 32-bit.
  3. Change the default target platform AnyCPU to x86.

If you compile as AnyCPU and run your application on 64-bit platform, then you won’t be able to load the 32-bit DLL file.
If you compile as x86, then the 64-bit system will run your application in 32-bit mode, and you’ll be able to load the 32-bit DLL file.

Good Morning Support Team,
Again, I thank you for taking time to respond to the few points I raised in my earlier note on this topic. To me, by far the most significant comment of yours concerns the ability of Microsoft Visual Studio, when configured as a 32 bit environment, to be able to operate with your DLL’s. This is at variance with the statement in the VM167_DLL_Manual.pdf, which states: “Microsoft Visual Studio users please note: The VM167.DLL is a standard Windows DLL, you cannot reference it.” On the basis of this statement I installed the Visual Basic 2008 Express, but I already had the 2019 Viisual Studio installed. I will transfer my code to this latter platform, and ensure it is configured for 32 bit and x86, as you suggest.
Many thanks,
Ian

This notification was added to notify Visual Studio users that the VM167.DLL is not a .NET assembly file. The file extension of an assembly file can be .DLL, which is very confusing.
According to this document you can add a reference to the following types of components and services only:

.NET class libraries or assemblies
UWP apps
COM components
Other assemblies or class libraries of projects in the same solution
Shared projects
XML Web services

There should not be any problems using the Visual Studio 2019 instead.