Must we rebuild our code to use a newer version of LabJack

4 posts / 0 new

Thu, 06/08/2017 - 15:08

WillyNilly

For many months, we used LabJack U6's with v3.46 software. We use VB.Net.

Throughout this time, we found that if you tried to use any subsequent version of LabJack, it would not run. So, we forced everyone to install 3.46.

Now that we started using Windows 10, we learned 3.46 will not work. Everybody now uses 3.50.

We do not have this problem with DLLs that we make, or from other third parties.

Is this an issue that is understood?

Thu, 06/08/2017 - 19:20

LabJack Support

Your application binds to a

Your application binds to a specific version of an assembly. In the case of your application, it is built referencing LJUDDotNet.dll (assembly) version 3.46, it binds to it and will require that version. This is default .NET functionality. I believe assemblies can have publisher policies to redirect old versions to the current version, but LJUDDotNet does not have this. Here are some solutions to this:

1. Distribute your .NET application with LJUDDotNet.dll version 3.46. You can put the dll in the same directory of your VB .NET application's executable. Note that LJUDDotNet.dll version 3.46 is compatible with newer versions of the UD driver (LabJackUD.dll) such as 3.50.

2. Make a config file for you application that redirects LJUDDotNet version binding from 3.46 to 3.50. For example, if your application is MyApp.exe, in the same directory make a MyApp.exe.config file with text like:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
<runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="LJUDDotNet" publicKeyToken="9d6c109908595016" culture="neutral" />
        <bindingRedirect oldVersion="3.46.0.0" newVersion="3.50.0.0" />
      </dependentAssembly>
    </assemblyBinding>
</runtime>
</configuration>

3. Recompile your application to reference LJUDDotNet version 3.50.

4. Install our software with UD driver version 3.46. I recommend the other solutions over this one though for the latest UD driver updates.

Tue, 10/31/2017 - 15:39

WillyNilly

Did you read the part about

Did you read the part about how we rebuild our own DLLs, give them higher version numbers, and they work great with code that was written years ago?

Likewise with DLLs we get from vendors. Unless they have changed the interface, newer DLLs work with code that was compiled against older ones. It's how the world stays sane.

Think about it.