ANT Forum

Hi

I am using Visual Studio 2015 Community Edition on Windows 10. I can build and run ANT_NetDll_Demo but when I debug my own project I get the following error:
Exception thrown: 'System.DllNotFoundException' in ANT_NET.dll
Error: Unable to load DLL 'ANT_WrappedLib.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)

I have followed the advice in this thread http://www.thisisant.com/forum/adopter-zone/viewthread/1584/ and the following code run before calling the ANT_Device() constructor says the file exists:
string curFile = Directory.GetCurrentDirectory() + @"\ANT_WrappedLib.dll";
Debug.WriteLine(File.Exists(curFile) ? "File exists." : "File does not exist.");

I don't know if this a Visual Studio 2015 issue or ANT_NET.dll but I'm struggling to see why my project won't run.

Thanks in advance for any suggestions.

Mike      

Shane.
I am seeing something curious like the OP and can reproduce it 100%. First of all, I AM copying all .dlls into the executing directory. ANT_Net.dll as a reference, and the others as "copy always" to the build output directory. I also package files in my installer carefully from the same output directory into the installer.
This has worked historically with the older Windows SDK prior to 3.5.

The first access to ANT_WrappedLib.dll will throw an "not found error" on systems that have not, for example, updated using the Garmin Express update, which I noticed also uses the 3.5 sdk files. Uninstall that product and all files it installs (that's an uninstall option) and bang, suddenly the ANT_wrappedLib.dll which is clearly in the executing directory of my app, appears as not found. Install Garmin express' update, and wham, all is back to working just fine.

The error throws at
AntDevice = New ANT_Device()

where ANTDevice is of type ANT_Device. I note with interest how one poster historically showed that this statement in VB.net threw this very error but in c# did not. Of course my whole app cannot be easily ported, it's mature product of 10 years. Is there a VB.net build setting I can tickle to make this work right?

I am currently telling my customers to install the Garmin Express update, and while it does not install new drivers, I think it is installing some necessary new bit maybe in the GAC relating to libusb-win32 (that appears above the devices in device manager).

Can you please perhaps comment? I absolutely swear the ANT_WrappedLib.dll is in my application directory and it IS the correct version with respect to the other files in the SDK. I would like a phone conversation if possible, and will call if you can provide contact.

     

Okay I can correct a bit. this does seem related to the libusb-win32 existing in some form. However despite it existing making older versions using the older SDK files "work", it seems the 3.5 SDK doesn't just work the same way and needs an update that appears embedded nicely in Garmin Express. Can you give me guidance on the differences, how they arose, and perhaps a better solution that requiring Garmin Express? I am looking at the sourceforge usb and github libusb projects.
     

that link busted, but I have seen you post that before and am following it.

Yes, this happens when fully installed on people's systems so the executing directory is the only one around, as well as when I execute from the output directory (launching with no VS in sight).


     

Also, this issue only began at customers when I moved to the newer 3.5 binaries.

     

Any possibility this is result of VS2013 built the sdk 3.5 and I am using vs 2012 for my build. .net 4.6.1?
     

wow I had a full summary took 30 mins to type. got punted. DANG.

Mostly resolved, and it isn't about the .dll chain and it isn't about VS using the project directory in debug. Don't know about you, but all my builds execute from the build output directory referencing always .dlls in that directory first...always, and in fact I can't even find how to configure otherwise! Maybe its a setting, or a quirk in a different language.

I can only conclude that my customers have somehow been using an older libusb-win32 and driver package (although I KNOW one had up to date device drivers for sure, can't say about libusb-win32) that somehow don't accept the SDK version 3.5 libs. If they had installed a Garmin Express (even of quite old vintage) then everything works fine, there is not even a need to update the GE to work with the new 3.5 SDK. Can only conclude it's in a bad or outdated libUSB-win32 people have going on. All of my customers who experience the problem (who have told me) have said they think they've never installed GE but got the ANT+ working by either straight PnP or loading something else. Most can't remember, of course.

Anyway, I leave this here in case others have more insight, and if they encounter same pains when first adopting the version 3.5 SDK libs in product.      

Nope.
I have been building against x86 from day one. In the Compile settings, (Project properties -> compile -> Target CPU) it is set to x86. It is because all .dlls from 3 parties were/are still provided in this form. Without that setting, a runtime error occurs that indicates incompatibility of the .dlls upon their first call. That happens against the .dlls in the lib so you can't get far when it's wrong.

Now, the full project settings in the IDE are set to Any CPU but these have never been consequential, the final Compile setting seems to be the critical factor here, at least as far as I know and It worked without issues UNTIL I used the new libs in SDK 3.5. I had customers (and myself) demonstrate that the old libs worked fine, same build configuration, older libs, and would fail on the user's machine (and one I discovered and borrowed until I could reliably trigger the issue on my own) when the same build with new libs was tried.

I am building on .Net 4.6.1 and I am relying on 3rd party libs that are provided on 4.6.0 or 4.5.0 if I wanted. Using WPF and VS2012. VC++ 2008 is prerequisite for some of my libs AND I add the VC++ you guys spec for the libs ALSO as a prereq, JUST to be sure.

I have 2015 but see no changes when I test a build using that and muck about with the GExpress loaded vs removed phenomenon.

so far, all I can fathom is a change in how libusb-win32 somehow sees the ANT_Wrapperlib.dll as valid. Very curious that the error isn't "run time error wrong kind of dll" but "it just ain't there".

I just also had one more data point come up today. Stick in a new stick never before seen by the system since drivers GE installed. watch driver load. Cool.

Upon running GE and clicking "Add device", if it comes up with none "We found a stick but no devices to talk too", then terminating GE somehow still locks down the stick (yes, the options to not run in background are off) !!! Other apps cannot access the stick and the error "Can't find that ANT_Wrapperlib.dll". Now, remove the stick from the port.
da-dunk sound of driver unloading.
Insert the stick.
da dink sound.
Run your application. Ahh, suddenly my application can see the Wrapper lib and the stick and all is cool.

I don't know at all if that helps you or that other guy who has posted with similar problems.
***********EDIT********
NOPE the above scenario is a red herring as far as "can't find ANT_WrapperLib.dll". The scenario described above leads to an ANT stick simply appearing itself as unavailable as if the termination of GE does not release the ant stick resource to make it available to other applications. It generates actually a different error. This will be sticky until you remove the stick and reinsert and not run GE and ask it to look for a devices. When GE can't find devices talking to the stick, then it seems this particular error will happen until the stick is moved and reinserted.
I think the two errors are different but certainly COULD be related. Sorry to mislead.
*************************



Thank you for your attention to this.      

bikesmelly - 14 March 2017 11:19 AM

Upon running GE and clicking "Add device", if it comes up with none "We found a stick but no devices to talk too", then terminating GE somehow still locks down the stick (yes, the options to not run in background are off) !!! Other apps cannot access the stick and the error "Can't find that ANT_Wrapperlib.dll". Now, remove the stick from the port.
da-dunk sound of driver unloading.
Insert the stick.
da dink sound.
Run your application. Ahh, suddenly my application can see the Wrapper lib and the stick and all is cool.

I don't know at all if that helps you or that other guy who has posted with similar problems.
***********EDIT********
NOPE the above scenario is a red herring as far as "can't find ANT_WrapperLib.dll". The scenario described above leads to an ANT stick simply appearing itself as unavailable as if the termination of GE does not release the ant stick resource to make it available to other applications. It generates actually a different error. This will be sticky until you remove the stick and reinsert and not run GE and ask it to look for a devices. When GE can't find devices talking to the stick, then it seems this particular error will happen until the stick is moved and reinserted.
I think the two errors are different but certainly COULD be related. Sorry to mislead.
*************************

Just tested this and as you noted this seems to be a separate issue of Express not releasing devices properly when terminated.      

Sorry for replying to an old thread, however this seems to be the top location for information on this issue so wanted to add my findings too.

We just updated our app to SDK 3.5 as well and about 5% of our users, across both Windows 7 and Windows 10, encountered this error. We tracked down the cause to the Visual C++ 2013 redistributable not being installed. Specifically, msvcp120.dll and msvcr120.dll were missing. We solved it by bundling those two DLLs along with our application, however installing the redistributable (the x86 version) would also do the trick.

The previous version of the SDK we were using used the Visual C++ 2008 redistributables (msvcp80.dll and msvcr80.dll) which apparently were already installed on all our users' machines.      

mdlieder - 08 March 2019 10:00 AM

Sorry for replying to an old thread, however this seems to be the top location for information on this issue so wanted to add my findings too.

We just updated our app to SDK 3.5 as well and about 5% of our users, across both Windows 7 and Windows 10, encountered this error. We tracked down the cause to the Visual C++ 2013 redistributable not being installed. Specifically, msvcp120.dll and msvcr120.dll were missing. We solved it by bundling those two DLLs along with our application, however installing the redistributable (the x86 version) would also do the trick.

The previous version of the SDK we were using used the Visual C++ 2008 redistributables (msvcp80.dll and msvcr80.dll) which apparently were already installed on all our users' machines.

This worked for me. Thank you very much !