First I would question whether you really need the Datawedge API in your app. If you just need Datawedge to be disabled when your app is running, you could create a new datawedge profile with your app associated with it, disable that profile, and then when your app is running, datawedge will be disabled.
In datawedge config, go to Advanced/Profiles/Add new/ Make up a profile name for your app, then hit save. Then in that profile, uncheck enabled, and in the applications tab, add your exe name, hit enter, then the zero key a bunch of times to back out of the config utility. You should see that when your app comes up, datawedge disables itself, so your app should be able to control the scanner.
If you really do need the datawedge api, try building the sample app that comes with that. I just built it, it works on a device, and here's what I ended up with in my bin folder.
10/23/2014 10:47 AM 11,776 CSharpDWAPISample.exe
10/23/2014 10:47 AM 26,112 CSharpDWAPISample.pdb
10/23/2014 10:47 AM 24,576 Interop.DataWedgeLib.dll
Thanks for the response. The problem I have with taking the profile route is that the App we're creating will be shipped to a lot of (remote) Motorola devices and installed by non-techies (shopkeepers). The very specific request we've had for the development is that the end user should just be able to double-click the CAB file and the package gets installed. As frustrating as this limitation is, it means we can't expect several hundred people to all setup a profile manually, so I'm not sure that's an option - I was hoping for a way to do what I need programmatically,
As for the sample app, you're absolutely correct. I ended up with exactly the same as you. This was also true when I built my own application. However, if you then add a Smart Device CAB Project and add the sample app's Project output, the CAB Project picks up the following 'Detected Dependencies' : mscorlib.dll and mscorlib.tlb from the full NET Framework (as well as mscorlib.dll from the Compact framework), stdole.dll from my PC's Windows GAC, and the Interop.DataWedgeLib.dll from my project's output folder and this is the problem I'm concerned about - it's as if the DataWedge API has been built to depend on files from the Full Framework!
1 of 1 people found this helpful
I see what you're talking about now. Not sure why that's happening, but it looks like you can fix it in the CAB project by excluding the files that you don't want, and unexcluding the ones you need.
I built one out of the demo project and set exclude to true on DataWedgeAPI.tlb, mscorlib.dll (both instances), mscorlib.tlb, and stdole.dll.
I set exclude to false on Interop.DataWedgeLib.dll, System.Data.dll, System.dll,System.Drawing.dll, System.Windows.Forms.dll and System.Xml.dll. If you look at the source path for each of these they all are coming from a Compact Framework folder.
I can then build a cab file that is 503k and it works when I install it.
Fantastic. Thanks for that. Had a bit of play around now and your advice looks like the way to go. Ran some tests and it looks like the DataWedge API works fine, even without the explicit, full NET framework libraries being included in the CAB. Does seem a little odd that it picks those libraries up, but at least I now have a workaround.
Many thanks for your help and feedback