manage 3rd party dll versions

[johnc]

Hi,

I have been using a Silicon Labs USB to UART bridge device for some time.

I have a number of CVI applications that use Silicon Labs DLL and Windows driver to communicate with the bridges.

The USB Windows driver matches the DLL.

Because the new revision of the DLL & driver is signifficantly different from the previous one,

I now need to maintain CVI applications that can be built using either version of the DLL. My source code is easy to control using

#ifdef, but I need something similar to use the correct LIB & DLL whne the application is built and run.

The best option I can think of is to have 2 projects. Both include the same CVI source files but include different DLL, LIB and H files.

Is there a better option?

Cheers,

John

[menchar]

John -

Something doesn't sound right here.

If they properly versioned the DLL, the newer DLL should work with the old application - that's the whole point of the DLL versioning scheme.  E.g., you don't have to rebuild every CVI application you've ever deployed if you happen to upgrade the CVI runtime engine (which is itself a set of DLL's).  When using C and implicit linking of the DLL at application load time, the functions are called by name and the application can bind to the same functions in the new DLL.

If the versioning is broken (i.e. they changed function signatures), then two separate projects is a way to deal with it.  At least with CVI 8.x you can have the projects in the same workspace so it's not such a hassle to manipulate them.

And when you deploy your applications, if they're on the same machine you need to make sure each app finds the DLL version it needs.  You can also hook up code to programmatically determine the DLL version and report it to the application at run time.

Menchar

[johnc]

Hi Menchar,

It might just be my missunderstanding but:

Two of the DLL functions have additional calling parameters in the new version. That sounds like your description of "broken" to me.

I'll look into the Silicon Labs support forums and see what others are saying.

I don't think it makes sense to have 2 versions of the DLL on the same PC.

The DLL has to match the Windows driver (a new version was issued to match the new DLL) and the pre-installer for the new driver removes the old one.

My issue is that I want to develop new applications with the new DLL/driver while continuing to support old ones on the same PC!

That means maintaining older applications (changes not related to USB) with the new DLL/driver on my development PC. Then building for deployment with the old DLL/driver.

Thanks for your input.

John

[menchar]

Yup, adding a parameter to a function changes the function signature and breaks the interface.

A better way to do it is to make a new function with a different name to take the new parameter.  That's why you see, for example, Win32 API calls of the form function () and then later functionEx ().    Older apps using function() don't have to be rebuilt to use the new DLL that contains both function() anf functionEx().

It sounds from what I know of it that they didn't do a good job with the versioning, unless they were forced into it by something microsoft did.

If you run one app or the other on a given PC, then no, you don't need both versions of the dll obviously.  But if you did, there are ways to manage the DLL search path to ensure each app gets the dll it needs.

Good luck.

Menchar