Why does NI-USI require the NI License Manager?

[D_Biel]

You assumption that the NI Library installer includes the VC dependencies should be correct. In this case it, it is a bug that it does not include the VC runtime. We are fixing this for the next release. But with other libraries you can expect them to include their own dependencies. If they do not, then please let us know so that we can investigate and resolve the issue.

[tstanley]

The other problem I ran into is this:

I have a distribution built on a Windows XP PC with CVI 2010SP1 installed (as well as several older versions of CVI).  It is set to install the CVI runtime engine into the application directory, and the under the subsection for the CVI runtime engine in the Edit Installer dialog, the "Standard Run-Time", "Intrument Driver Run-Time", and "Analysis Support" is checked, and the others are unchecked.  NI-USI 1.9 and NI-Visa Runtime 4.6.2 are also selected.  This distribution kit installs and runs fine on deployment systems (running Windows XP and Windows 7), and also runs just fine if I install it on the Windows XP development computer.  However, on my other development PC, a Windows 7 64-bit with CVI 2012 installed when I try to run the application I get the following error:

 

I surmised that it was a problem with the two different runtime engines and when I manually delete the runtime engine components out of the installation directory the application runs fine (presumably going to the 2012 runtime version installed in the System32 directory).  I don't consider it a big deal for my application because I want to move away from installing the runtime into the application directory but you may want to know about it.  Thanks.

[D_Biel]

Hi TStanley,

This is not expected behavior. Since you built against the 2010 SP1 RTE, it should be fine running against that version no matter what. This sounds like another dependency issue. Could you create the dependency walker and process monitor logs again? Logs of the Win 7 x64 system with and without the 2010 SP1 RTE dll.

[tstanley]

Hi D. Biel,

I sent an email with the log files attached.  Thanks. 

Edit:  The attachment was too large.  Is there another way I can send the files?  Alternatively if the Dependency Walker files are enough those are quite small in comparsion.  Thanks. 

[D_Biel]

The Dependency Walker logs tend to be more helpful, so you can send just those.

[tstanley]

Hi D. Biel,

The logs are sent.  Thanks. 

[D_Biel]

Hi TStanley,

You are actually hitting two known issues here.

1. Instrsup.dll is not forward compatible under certain circumstances. Instrsup.dll is the library installed by the Instrument Driver Run-Time component. This means that if you are using the 2012 instrsup.dll with the CVI 2010 RTE, it will not run. That is why when you hide the 2010 RTE, it begins to work. This can be avoided by disabling the "Enable LoadExternalModule" checkbox in Build >> Target Settings. If you disable this option, then instrsup.dll will be compatible with the older version of the 2010 RTE.

2. The second part is why you have the 2012 version of instrsup.dll instead of the 2010 version which is included in your distribution. This is related to known issue #309109 where the instrsup merge module is not installing instrsup.dll into the application directory when specified to do so. Instead, it is attempting to install it to the System directory, but because CVI 2012 is already installed (and thus the 2012 version of instrsup.dll is installed), it will not install. To fix this, you could also include the 2010 version of the instrsup.dll from your development system into your distribution so that it will be in the application directory on the target system. This issue has been fixed in CVI 2012 by the way.

[tstanley]

Hi D Biel,

Thanks for looking into this.  While I plan on installing the runtime engine to the Windows directory (and moving to CVI 2012) it's good to know what's going on with the applications we have already built and how to fix this issue if it comes up.