C++, my almost favorite language. This language had good intentions, really. But this is such a pain -- a  pit of despair -- to have to deal with library compatibility and compilation parameters matching issues, where it should be handled by the system.

Anyway, if you're trying to use the Broadcom Bluetooth SDK for Windows CE with VS2005 or VS2008, you might encounter this pretty message :

error LNK2019: unresolved external symbol "__declspec(dllimport) public: int __cdecl CRfCommIf::SetSecurityLevel(wchar_t *,unsigned char,int)" (__imp_?SetSecurityLevel@CRfCommIf@@QAAHPA_WEH@Z)

The symbol actually exists in the broadcom provided library (BtSdkCE30.lib or BtSdkCE30.lib)  but is defined like this :

SetSecurityLevel@CRfCommIf@@QAAHPAGEH@Z

which, undecorated, means :

int CRfCommIf::SetSecurityLevel(unsigned short *,unsigned char,int)

See the difference ? The wchar_t type the compiler is using should be an unsigned short. Basically, both types are binary equivalents but the compiler is treating them as different, hence the different signature.

To fix this, just set the option "Treat wchar_t as Built-in Type" to No.

This way, the wchar_t will go back to being a short, and then match the method built in the static library.

I'm going back to my C# code, now.