NationalInstruments.DAQmx.DLL versioning

[lorenzpurple]

Hello, I'm developing my apps using C# and NiDaq.

After some time, we have some customers with NiDaq 8.3.1 installed, and some others with 8.6.1.
My application, which now uses in some case specific function related to 8.6.1, like "AdcTimingMode",  on the old customers, could still work, as
that function is dynamically loaded, after application startup.

But I've referenced on my application 8.6.1. DLLs, so when the application starts on a machine with 8.3.1 installed, i get :

System.IO.FileLoadException: A procedure imported by 'NationalInstruments.DAQmx, Version=8.6.20.15, Culture=neutral, PublicKeyToken=4544464cdeaab541' could not be loaded.
File name: 'NationalInstruments.DAQmx, Version=8.6.20.15, Culture=neutral, PublicKeyToken=4544464cdeaab541' ---> System.Runtime.InteropServices.COMException (0x8007007F): Impossibile trovare la procedura specificata. (Exception from HRESULT: 0x8007007F)
   at WindowsApplication5.Form1.Form1_Load(Object sender, EventArgs e)
   at System.Windows.Forms.Form.OnLoad(EventArgs e)
....


I've already tried playing with the following :

<?xml version="1.0"?>
<configuration>
    <runtime>
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
            <dependentAssembly>
                <assemblyIdentity name="NationalInstruments.Common" publicKeyToken="4544464CDEAAB541" culture="neutral"/>
                <bindingRedirect oldVersion="0.0.0.0-8.1.20.237" newVersion="8.0.20.278"/>
            </dependentAssembly>
        </assemblyBinding>
    </runtime>
</configuration>

that is, referencing the old DLL, so that I could startup in some way, and then load the right DLL, but still no luck

I really don't want to update all the old customers, as they really don't need this upgrade, and I can't create different
versions of the application...

I need some way to force the application to start, using the DLL that it finds in place (I would prefer it than the GAC)

Many Thanks,

Lorenzo

[JonathanN]

Hi Lorenzo,

I first wanted to make clear what we support with regards to DAQ versioning.  The DAQmx API is backwards compatible meaning that we guarantee running older versions of a DAQ application against a newer version of the DAQ driver will work and won't break your application.  This basically means that the requirement for DAQ versioning we support is that whatever version of the DAQ driver you build against (in this case 8.6), the target machines must have at least that version or higher installed.  This means that your customers need to all have version 8.6 on their machine if you are building a DAQmx application against the 8.6 driver.  This is a stance that NI has made as a whole.  This is the recommended and supported practice for using DAQ and therefore I am highly recommending that you follow this practice.  To ensure this practice, the best option for you since you have 8.6 on your dev machine is to build against 8.6, create an installer that includes the DAQ assemblies and the DAQ 8.6 driver and install that on your customer’s machine. This will ensure that those machines have 8.6 and the 8.6 assemblies.  In this scenario, you won't have any problems at all.

Now, if you want to try and workaround that (which I don't suggest), your best option is to componentized your application.  By that I mean have a main EXE that first checks to see what version of the DAQmx driver is installed and depending upon that check, the app loads a "8.3" DLL which loads the DAQmx 8.3 assembly or a "8.6" DLL which loads the DAQmx 8.6 assembly. To set that up, I believe you could essentially have two separate projects in your solution with one for 8.3 and one for 8.6.  For each project, you would reference the specific DAQmx assembly (i.e. 8.3 would reference 8.3 and then 8.6 would reference 8.6).  You would need to load them through reflection via Assembly.LoadFrom in order to load up the specific version.  You would need to keep those different versions of the DAQmx assemblies in different folders. You might find better options that what I have suggested but this is just something to ponder on.  You may have to twirk some things along the way, but I believe this should work.

Again I would recommend my first option if at all possible.

Hope this helps!

Best Regards,

[lorenzpurple]

Hello Jonathan

Thank you for your suggestions, too bad I'll have to follow the first option.
I've tried now to get on the second solution, which I can't use...
By now, the references to the national functions are too much radicated, I should take them out the main source,
thus rewriting quite some code...
Also I would have to replicate the acquisition code, on two (by now...) projects, that could grow in the future...

So I'll have to update all the actual customers, hoping not to be in the same situation for the future.

Anyway, I've seen the driver installer has a new function (metainstaller) which is just a great new thing.

As I see that there is no hope for a small-footprint or customizable driver targeted to DAQ and .Net,
a question :

By now, the driver installer checks for all the components to be in place, before starting.
Why not add, as an option, that this driver installer don't check for all the packages to be there ?

I've done many tries, finding out that the only services I need for DAQ and C#/.NET to work are

"NI Configuration Manager" (nimxs.exe)
"Device Loader" (nipalsm.exe)
and the real driver (for me this is niemkrw.sys).

Which CABs I need to get USB 9211A and 9219 to work on windows with C# / .Net ? is there somewhere a list
of the needed ones ? I've tried a lot of combinations, working on virtual machines, but still I get
an AccessViolation (0xFFFFFFFF) when I try to start the services.

Best Regards

[JonathanN]

Hi Lorenzo,

I'm glad you are going with the first solution.

The best place I can refer you to is the Deploying Measurement Studio Applications help topic in the NI Measurement Studio Help. This help topic and its subtopics explain what merge modules and files you need to include in your installer to appropriately deploy your application. In this post, I talked about options of bundling the DAQ driver with your VS installer. The end solution is that you need to install the actual driver (not specific parts like CAB files) onto those target machines.

After reading my post and through those help topics, if you still have questions, let me know.

Best Regards,

[lorenzpurple]

Hello again

I've read your post, and I've now another question 😃

LabWindows/CVI (which I suppose means Measurement Studio) will create an installer (.msi)
from VS2005... but this installer will get only the needed files for the targeted device (or device class),
thus dramatically reducing the size, or will embed the whole driver (1 Gb for the 8.6.1 version) ?

Also in my opinion it is much better to upgrade the driver to the customer, making a single source
for every one, as having many satellite and different assembly could lead to unpredictable cases...

But I need to reduce the size, some customer are still on analog modem lines, being lost in some far jungle...
(and the upgrade size of my application is at 1 Mb)

Best Regards

[JonathanN]

HI Lorenzo,

That post did talk about LabWindows/CVI for a specific reason. You see, LabVIEW and LabWindows/CVI both sit on top of our meta-deployment framework which means that when you create an installer in those IDEs, you have the option of bundling the actually hardware driver with it. In this case, you can bundle the DAQ driver as shown in the attached LabWindows/CVI screenshot. The reason I mentioned CVI is because we actually allow users to choose "watered-down" versions of the DAQmx driver in that IDE (as well as LabVIEW). 

Currently, Measurement Studio doesn't support this framework and thus there's isn't a direct way to bundle your .NET application with the low-level drivers. This is something that we are considering implementing in future versions of Measurement Studio. Therefore after you create your .NET application installer (which contains the DAQmx assemblies, your actual application, any .NET dependencies, etc), you will need to somehow bundle the downloadable version of DAQmx which is the full DAQmx installer.  In this case, you don't have access to the watered-down versions of DAQmx.

So for those customers who had CVI or LabVIEW, I suggested build a CVI or LabVIEW installer that just had the watered-down versions of DAQmx and then combine that with the .NET installer.

The DAQ team is aware of the "large" footprint that the DAQ installer makes and is always trying to reduce that size. We did have reduced run-time engines for DAQmx 8.3.  Now if you would like, I can always build a "reduced DAQmx" installer in CVI for you and post that to our FTP site. If that's and option you would like to consider, let me know which run-time engine (5, 4, 3, etc) you would like. 

Best Regards,

[lorenzpurple]

Hello Jonathan

Thanks for your support. Indeed, I'd like to try a functioning runtime engine.
Quite a year ago, I've tried the runtime engine for 8.3, but none of them was good or working for me.
(All Runtimes where lacking Measurement Studio)
I also received from the Italian support a compiled installer, which wasn't working correctly.

What I need is a reduced installer that includes :

- C# / .Net support (NationalInstruments.DAQmx.dll, to say)
- Ni-Daq 8.6.1 (for these USB devices : 9211A , 9215, 9219 and 9204)
- NI Device Loader/ NI Configuration Manager Services
- Measurement & Automation ( if it grows with more than 10 Mbytes with that, just remove it )

Thank you and best regards!

[JonathanN]

Hi Lorenzo,

What I was suggesting is that I create a DAQmx installer (one of the 5 optional runtimes) which soley has the DAQmx underlying functionality. You need to create the Visual Studio installer which incompasses your application and the DAQmx merge modules. This is all documented and explained in the Deploying Measurement Studioi Applications help topic that I mentioned earlier.

The smallest size that is available is with Runtime 4 which when built into a MSI turns out to be 131 MB which basically includes the underlying files needed to run a DAQ application. It doesn't include any ADE support for LabVIEW, LabWindows/CVI and Measurement Studio, the DAQ Assistant, the NI-DAQmx documentation, and Real-Time Support. This is the only option available to you.

If you would like that, I can post it.

Best Regards,

[lorenzpurple]

Hello, 131 Mb or 80 Mb ( which I remember was the size of an installer I saw) is still too big for remote assistance...

I now that It can lowered to about 15-20 Mb (I've tried many times to install manually just the neede MSI files,
I just still get some problems on the final device loading)

any hope for such size ?

[Colin hughes]

Hi Jonathan

Ok by me as I would not expet any software to be forward compatible unless you wright a software cristal ball but then I only create inhouse programs.

Colin