Hey Derrick,
I think if you are stuck using 3rd party software developed with no regard for backward-compatibility, you will have no other choice but to use a work-around. Nevertheless, I agree - I don't think you should use a work-around unless it is necessary. Maybe you can discuss with the 3rd party team and ask when they expect the interface of the features you use to be stabilized. That may be difficult if can't even get them to admit that a fundamental change like a return going from an integer to a floating-point value constitutes a change to the interface. I realize that it may not be possible, but if you really can't get support for something so basic from the vender, you probably should run away as fast as possible. Any respectable .NET development team knows the value of backward-compatibility and .NET makes it extremely easy to support it. If you are sure that the interface really did change from version to version, I think you really need to resolve this with the vender.
As far as the work-around goes, I was recommending bundling copies of the API DLLs with your LabVIEW executable - that will ensure that the version of the DLLs that you are directly calling don't get overwritten if your customer decides to install an updated version of the API and would sidestep potential weaknesses in LabVIEW's GAC integration. If, on the other hand, new features of the new versions of the API will need to be leveraged as they come out, I don't see a clear work-around - you will need to re-build the application for each version. Note that this idea is not foolproof. There may be other dependencies that aren't obvious and that could screw up the work-around. Yet another reason to sidestep the whole situation if possible.
Good luck,
Rob
