This has not been updated for version 3.2. See the readme in the release for current information
This was new support in version 2.4. In 3.0 we have done a lot of work to ensure that all functionality works from asynchronous callbacks, new features include setting BluetoothRadio.Mode on CE/WM (there’s no Widcomm API on Win32), correctly reporting the Mode when the radio is disabled, support for InquiryLength in DiscoverDevices, and closing all connections when the radio is switched off. In 2.5, there were improvements to diagnostics on setting-up dependencies and BluetoothListener was rewritten amongst other changes.

To enable the Widcomm support, in brief the 32feetWidcomm.dll native DLL need to be present at runtime in the same folder as the main library assembly (InTheHand.Net.Personal.dll) and the application itself. As a native DLL it cannot be referenced at compile-time like a normal managed .NET assembly.

Also, Win32 needs a particular version of the Visual C++ Runtime libraries, since 2.5.1 this is version 9.0.21022.8, and can be found at “Microsoft Visual C++ 2008 Redistributable Package (x86)” (Version 2.5 required version 8.0.50727.4053. If not already installed, this can be found at “Microsoft Visual C++ 2005 Service Pack 1 Redistributable Package ATL Security Update”

In more detail, Since the Widcomm API is C++ and thus can’t be P/Invoke’d directly we unfortunately require a native DLL as well as the normal library assembly. Versions of the native DLL are supplied primarily for Win32 x86 and WM2005, we also include PPC2003 and Win32 x64 but we don’t/can’t test them. At runtime the 32feetWidcomm.dll DLL needs to be present alongside the library assembly (or somewhere else in the path presumably), there is no need to reference it at compile-time (as a native DLL is can’t be referenced like a .NET assembly).

For Widcomm, various users have reported that there are problems on desktop Windows with newer versions of the Widcomm stack, with for instance BluetoothClient.Connect failing with a SocketException with it message including the code “PortLookup_NoneRfcomm”. We now supply two versions of 32feetWidcomm.dll for Win32 for this reason. Unfortunately when to use them is complex— I wish Widcomm had been a bit cleverer about how they provided their Vista support. :-( (Note that Bluecove on Java also has to supply two versions of the DLL presumably for similar reasons ).
  • Normal 32feetWidcomm.dll version
Works even when the Microsoft Bluetooth stack is also active, and so allows multi-stack support. But might not work on newer version installations of the Widcomm stack.
  • “SDK6” version
May be required on newer version installations of the Widcomm stack, but will not work when the Microsoft Bluetooth stack is active.

We also now include copies of the 32feetWidcomm.dll for x64, let me know if it works for you, it is untested by us.

There are no further dependencies on Windows Mobile but there is on desktop Windows. That’s the ‘C Runtime’ (CRT) libraries as described above. If the correct version is not installed, then the Widcomm support in the library will report that it can’t load the 32feetWidcomm.dll — even if it’s present in the same folder as the application/library. To check this, run the test app ‘Test32FeetWidcommWin32.exe’ which will report something like: “This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.” Installing the CRT will fix this. See the Widcomm document for more information.

We also need the Widcomm btwapi.dll in most cases. It is included in the 3.2 release if your machine does not have it.

Last edited Apr 25, 2012 at 8:35 AM by alanjmcf, version 1


No comments yet.