Can I install 8.1 RTE with InstallShield rather than distribution kit?

[BrionF]

Hello

I have an application developed in Labwindows 7.1 that I would like to deploy with the 8.1 RTE.  We would like to use InstallShield to deploy this application, but I'm a little unclear about the differences between installing the 7.1 RTE with InstallShield and installing 8.1.  From looking around here it seems like the install of the RTE may have changed significantly.

Any help would be appreciated.

Thanks.

Brion

[Mert_A.]

I'm assuming you've used InstallShield to deploy your app with the 7.1 RTE before? If that the case, I don't think it will be much trouble to update to 8.1. The CVI distribution builder began supporting full, separate installer bundling in CVI 8.0, from which point on it allowed distribution of the CVI RTE in that form, but the old merge module based distribution method is still supported, too. You'll find all the necessary msms in the Program Files\Common Files\Merge Modules directory now, rather than in a CVIXX\redist directory. In version 8.1, the top level CVI RTE merge modules are:

• cvirte_core.msm (core library support for projects linked the "Full run-time engine" in the Target Settings dialog)
• instrsup.msm (support for projects linked to "Instrument driver only" run-time support)
• cvi_lvrt.msm (support for projects linked to "Real-Time only" run-time support)
• nianlys.msm (support for the Analysis Library)
• ninetv.msm (support for the Network Variable Library)
• cvidotnet.msm (support for the .NET Library)
• ActiveX Container.msm (support for ActiveX controls and the ActiveX Library)
• cvirte_low_level.msm (support for the Port IO and Physical Memory Access functions in the Utility Library)

You can include all of these top level modules, or a la carte, as necessitated by your application. Note that each top level module may have a tree of dependency merge modules as specified by following the entries in the ModuleDependencies table. As you're probably aware, those modules will also need to be included. You should find them all in Common Files\Merge Modules as well, with the exception of niMetaUtils.ms, which is in Program Files\National Instruments\Shared\MDF\Bin.

Note that cvirte_core.msm replaces cvirte.msm, so don't include both. The latter is still installed for legacy support, but may not include support for newer libraries. The reason for the change was to separate the Analysis Library support out, which used to be a direct dependency. Now basic applications that don't use the Analysis Library can distribute the core RTE support and have a smaller distribution size.

I should also point out that there have been some reports of problems with niMetaUtils.msm in InstallShield 8 and 11. The following thread gives some details: http://forums.ni.com/ni/board/message?board.id=232&message.id=1968&view=by_date_ascending&page=1.

I hope this helps answer your question. If not, let me know.

Mert A.

National Instruments

Message Edited by Mert A. on 10-24-2008 11:25 AM

[BrionF]

Mert

Thanks for the quick reply.  A lot of good information there.

Unfortunately, I think I left out a very important piece of information.

The application was originally developed in LabWindows 6, and deployed with InstallShield.  So the files I'm used to seeing for the RTE are

• cvirte.dll
• cvirte.rsc
• and the CVIRTE directory with the supporting files

For our latest update, we've upgraded to CVI 7.1 for the development, and would like to deploy with RTE 8.1.  The filenames you listed are new to me.  Is there some resource you can point me to that documents what files need to go where during the install?

Thanks again.

Brion

[Mert_A.]

I'm sorry, I assumed that you had been using the RTE merge modules to distribute the RTE in your previous InstallShield package. I strongly advise against directly including the files/directories individually in your installer for several reasons:

1.  You can have issues with uninstalls removing files that are still needed by other applications. This happens because the reference counting built into the Microsoft Installer framework (MSI) will be broken if the same file is installed to the same location multiple times but not identified by the same component GUID.
2. If a new runtime dependency DLL is added in the future, you'll have no way of knowing. Basically, you'll have to keep repeating this kind of inquiry every time you want to update the version of the RTE you pack in.
3. Through addition of new libraries, the RTE has grown long dependency tendrils in different directions. The core functionality (majority of the libraries) is given by the files you listed previously, but various libraries may require additional files. For example, DataSocket requires dataskt.dll, DIAdem Connectivity requires cviUSI.dll, the Internet library requires cvintwrk.dll, and so on. Libraries that use shared NI components (e.g. Network Variable uses something called Logos underneath) may have much more complicated dependencies, for which I couldn't necessarily tell you how to properly install by hand.

The way around all of this is to use the merge modules that I discussed in my previous post. They provide a layer of indirection, so that dependencies or installation specifics may change from version to version, but your installer doesn't need to change. We make sure to be backwards compatible in this way; that's why we still install a legacy cvirte.msm, for example.

I'm not terribly familiar with InstallShield, but from what I understand, there is a scripting based version and an MSI based version. To use the merge modules, you would have to be using the MSI based version. If you're using the scripting version, I'm sorry to say I don't really have a good solution for you. You would have to just consider the 3 caveats listed above and try to figure out your working file set as best you can. At the very least, if you understand MSI tables, you could use an MSI database editor like Orca to examine the NI merge modules and use them as a guide for which files to install, and where.

Hope this helps.

Mert A.

National Instruments

[BrionF]

Mert

Our installShield expert has created an InstallShield package using the 8.1 RTE merge modules and my 7.1 developed application.

The install seems to go fine, but when I launch my app I get a

The application failed to initialize properly  (0xc0000005)

The RTE files included in the install are:

FileName Size  Version  Language  Sequence
 cviUSI.dll    104 KB   8.1.1.361   English (United States)   13
 cviauto.dll   348 KB   8.1.1.361   English (United States)   5
 cvierror.txt   23.3 KB   cvirte.dll1.AEE0121B_9196_4E7A_8C0F_7C1B926D077F   Language Independent   11
 cvintwrk.dll  100 KB   8.1.1.361   English (United States)   12
 cvirt.dll     44.0 KB   8.1.1.361   English (United States)   1
 cvirt4.rsc   256 KB   cvirte.dll1.AEE0121B_9196_4E7A_8C0F_7C1B926D077F   Language Independent   7
 cvirte.dll   2.75 MB   8.1.1.361   English (United States)   6
 cvirte.rsc   256 KB   cvirte.dll1.AEE0121B_9196_4E7A_8C0F_7C1B926D077F   Language Independent   4
 cvitdms.dll   116 KB   8.1.1.361   English (United States)   14
 dataskt.dll   124 KB   8.1.1.361   English (United States)   8
 msgrt4.txt   50.5 KB   cvirte.dll1.AEE0121B_9196_4E7A_8C0F_7C1B926D077F   Language Independent   3
 msgrte.txt   50.5 KB   cvirte.dll1.AEE0121B_9196_4E7A_8C0F_7C1B926D077F   Language Independent   2
 ni7seg.ttf   24.5 KB   cvirte.dll1.AEE0121B_9196_4E7A_8C0F_7C1B926D077F   Language Independent   9
 nisystem.ttf   48.4 KB   cvirte.dll1.AEE0121B_9196_4E7A_8C0F_7C1B926D077F   Language Independent   10
 

Any thoughts?

Brion

[Mert_A.]

It looks like you're not including the dependency chain declared in cvirte_core.msm's ModuleDependency table. Unless you're actually using the TDM Streaming library, I suspect your runtime errors are a result of the missing mesa.dll (NIMesaDLL.msm) file, which is necessary for drawing the rendered, "Lab-Style" controls of the UI library.

Make sure to always include the modules referenced in the ModuleDependency table, unless you know for sure the files will not be needed, or are already on all potential target machines.

Mert A.

National Instruments