Maestro dlls compatible with VS2005?

Hi,

Can you tell me if the USB Wrapper dll’s are compatible with Visual Studio 2005 c#?

I have run your 2008 example fine within my 2008 environment, but I have imported all the dll’s into a 2005 project and I can create an instance of a usc and settarget fine for a servo, but calling some of the other methods fail, i.e getVariables.

I am running Xp, SP3, VS 2005 SP1, .net 3.0/2.0. I have imported into my project the references to usbWrapper, Usc, ByteCode and Sequencer.

Thanks
James

UsbWrapper.dll (available in the Pololu USB SDK) was compiled to target .NET Framework 3.5, and was compiled in Visual Studio 2008. I don’t know if the Visual Studio version matters, but the target framework matters. Based on what I’ve read online, I think you’ll need to have the .NET framework 3.5 installed to run it.

Is there some reason you don’t want to install .NET framework 3.5 on your older machine?

I could pretty easily recompile UsbWrapper to target framework 3.0 and email you the DLL file if that is what’s needed.

-David

P.S. I changed the subject line to be more specific (was “Maestro USB Controller”).

Also, what happens when you run the get variables function? Is there an error message?

–David Grayson

Hi David,

I’ve recompiled the USC.dll with the 3.0 target and tried that but I still get an error, I can’t see where in the SDK the source code is for the USBWrapper to recomple it with 3.0?

The error is;

Method not found: ‘UInt32 Pololu.UsbWrapper.UsbDevice.controlTransfer(Byte, Byte, UInt16, UInt16, Byte[])’.

When calling usc.getVariables. It seems odd as the setTarget,setspeed commands all work and they run from the same classes.

James

We don’t distribute the source code of UsbWrapper.dll, but (as I said earlier) I could recompile it to target the .NET Framework 3.0 and email it to you. Send me a private message with your email address if you want that. But is there any reason you don’t want to install the .NET Framework 3.5 on your computer? My understanding is that you can have several versions of the framework installed at once and they don’t interfere with eachother.

Yeah, that seems odd to me too. But setTarget and setSpeed call a different method in UsbWrapper.dll, one that does not take a Byte[] argument and returns void. So I could imagine one of those overloads being backwards compatible with 3.0 and the other not being backwards compatible because it takes more complicated arguments.

-David

HI David,

I have installed 3.5 now, but I still get the error. It seems VS2005 doesn’t have the ability to set a “target .net” but will just utilise any additional components available in the newer versions of .net

I hadn’t realised that you worked for pololu, I will PM you with my details and I will try the 3.0 compiled version.

Thanks
James

Okay, I emailed you a version of UsbWrapper.dll recompiled for the .NET Framework 3.0. Let me know if it works!

-David

Oops, the email was blocked by our ISP’s virus scanner. You can just download the file here:

pololu.com/sfile/0J159764/66 … rapper.dll

-David

Hi David,

That has worked, although doh!, I made a schoolboy error. I checked the version of wrapper dll after reading you PM about the 1.1 and I had picked up the 1.1 version from the maestro example. I imported the 1.2 version from the SDK kit and that seems to work fine in VS2005 (3.0). But thanks for compiling a 3.0 as this might be useful for our app in the future.

James

I’m glad it’s working for you now! But I’d like to know more about what went wrong.

How did you accidentally obtain a copy of UsbWrapper 1.1.0.0 (the old one)? Did you download the SDK some time before February when we were distributing 1.1.0.0 and then download it later when it had 1.2.0.0?

Any way, why would that cause you a problem? Were you compiling with the new version and then trying to load the old version at run time by mistake?

The main difference between the two versions is that in 1.1.0.0, both overloads of Pololu.UsbWrapper.UsbDevice.controlTransfer return void, but in 1.2.0.0, the overload that takes a Byte[] argument (the one that was giving you an error message) returns a UInt32.

–David Grayson