How to know what files are needed for a given NI application

[menchar]

We are deploying multiple CVI applications to about 20 target systems.

We run NI Serial 1.8, and Measurement and Automation Explorer 3.1.1.

We do not run LabView, or use NI-VISA.

We seem to have a mess when it comes to tracking down what each application needs to use as far as rte's and other dll's and support files.

We see the LabView rte installed (sometimes multiple version) yet we don't use LabView and never will.

I'm not sure exactly how the LabView rte's are getting installed on our systems

We do install NI Measurement and Automation Explorer - does this use the LabView rte?

We see the NI VISA rte and server also, but we never use VISA.  Can we remove the VISA files and still have CVI (not using VISA), NI Serial 1.8, and Measurement and Automation Explorer 3.1.1 work properly?

We need to be certain of what we're installing and where it goes and which version is getting used, else we have nightmare scenarios when debugging anything that might be dependent on NI version, or when we're deploying a new target.

Is there anywhere on the NI website where NI portays all of the dependencies between the various NI applications and the ancillary files (rte's, VISA, etc.)?   

Thanks,

Menchar

[James M]

Hi Menchar,

Just to clarify, are you creating an installer in CVI that includes NI Serial or do you install the drivers separately?

Regards,

[menchar]

James -

We install NI Serial 1.8 separately, directly from the NI media.

The Measurement & Automation Explorer may have come in initially as part of an application distribution, but I suspect we installed it separately .  We don't include it with our normal CVI application distribution.

Then we install the CVI application.

Looking at the CVI application distribution kit setup, I see they checked "standard Run-time", "Analysis Support", "Active-X container support", and "NI-DataSocket".  Only the standard runtime is needed by the application if I can trust the module dependency checker built into the distribution kit manager.  I unchecked everything except the runtime and it builds without error.

Somewhere along the line we wound up with the LabView 7.0 and 7.1 rte's, and the NI-VISA 3.3.1, NI-VISA Runtime 3.3.1, and the NI-VISA server 3.3.1.

I wouldn't think we need any of these, unless there's some hidden dependencies.  I've tried eliminating NI-VISA from my CVI FSD istallation but it gets installed anyway.  But we never directly use it.   I'd just as soon not have any of these present, it just adds to the confusion from a configuration viewpoint. 

Thanks for your response.

Menchar

[menchar]

Some further info and questions.

Even when we specify "standard runtime"  only it looks as if we wind up with five (!) separate cvi dll's in the system32 folder.  Is this right?  Surely we don't really need all five dll's?

Secondly, how can I host multiple versions of the CVI FDS on my development system and be certain that I'm distributing the version of the rte that matches the version of the development system?  Where does the CVI framework get the runtime dll's that it includes in a distribution kit?

If I have, say, CVI 7.1, and CVI 8.0 both installed on my development system, what rte version will distribute with a distribution kit created with the 7.1 FDS?  How do I ensure that I distribute only the 7.1 rte when I create a distribution with 7.1 FDS?  How do I even know what the rte actually consists of? 

Thirdly, when I look in the add/remove programs wizard of WinXP Pro SP2, and I look to remove my application, I don't see a separate entry to remove the rte, and the rte doesn't seem to get removed when the application is removed.  So how do I remove the rte?  I can't do it with the Measurement and Automation Explorer either as best as I can tell, though the M&AE will tell me what's there.

Thanks,

Menchar

[Mert_A.]

Menchar,

Really, the number of DLLs that comprise the runtime engine is irrelevant. It is just a matter of dividing library support into multiple binaries. Now, you may or may not need every one of the DLLs. When adding a new runtime support DLL, we usually weigh its likelihood for wide use versus its file size when determining whether to make it part of the "Standard Run-Time" or a separate subcomponent. Reducing the number of separate subcomponents simplifies things and reduces the likelihood of missing runtime dependencies, but the tradeoff is an increased minimum RTE size for even the most basic apps.

As far as your second question, I think I've answered this for you before. The short answer is that anything before CVI 8.0 will distribute the version of the RTE that matches the development environment, but CVI 8.0 and later will distribute the version of the RTE installed on the system. At that time, you noted that there could be problems if the distributed app included anything but the system's installed runtime engine, which is absolutely true. That's why we made the change.

The RTE may or may not show up in Add/Remove Programs depending on whether you select the entire "LabWindows/CVI Run-Time Engine" in the Drivers & Components list or a subset of the components that comprise it. When you select a subset (or just "Standard Run-Time" in your case), the files are merged into your application installation and so do not have a separate entry in Add/Remove Programs.  If your distribution instead includes all the RTE components, you will get the full, independent RTE installer wrapped up in your distribution, and it will have its own Add/Remove Programs entry under National Instruments Software.  Note that which ever mechanism is used, the installed files will be properly reference counted and will not be uninstalled so long as some other installed application needs them.

Hope this helps.

Mert A.
National Instruments

[menchar]

Mert -

Thanks for the response.

Well, no, it does matter to us just what goes into the RTE, but for a reason that NI doesn't accomodate with the new 8.x application deployment scheme. 

We needed to go backwards and make sure we had removed everything that comprised the 8.1 rte to avoid a problem we were having with an application that fails serial i/o using the 8.1 rte, but works with the 8.0 rte.   As you point out the rte may or may not appear explicitly in the add/remove programs list.  So we needed to know just what we had to remove to get rid of the 8.1 rte.  As it turns out, there's an rte manifest in the CVI help I hope it's accurate.

Since 8.0, NI doesn't support multiple versions of CVI on the same machine, I hadn't fully understood this.  It is very confusing in that you can in fact install multiple CVI IDE versions but they will all distribute the single latest version of CVI that was ever installed.    After using CVI for decades this is a fundamental change that is causing us to retrench when it comes to understanding our deployment scenarios.

One of the historical advantages of the CVI framework over, say, Visual Studio, was that you could get a handle on the deployment model in a fairly straightforward manner, and there weren't lots of implicit dependencies that could create non-obvious behavior and lead to inconsistencies on various targets.   

It looks like I can force a specific version of the rte into the application folder and the application will use that rte despite a different version also existing and even being active on the system.

Menchar

[Mert_A.]

Menchar,

Historically, we have never supported more than one system-wide version of the RTE, even though we've supported side-by-side installations of the environment. This is nothing new.  What is new (as of 8.0) is that the distribution builder includes the system-wide version of the RTE, rather than a cached, environment-matching version of the RTE. This is preferable, because it ensures that a deployed app uses the same version of the RTE that it did when you ran it on your development machine.

It is a dark and scary path you are heading down by trying to manage individual runtime files by hand. The runtime engine does not have well defined boundaries, which is why that manifest-like help topic you found has become much less explicit (no filenames mentioned) as of CVI 8.1. We don't want to encourage users to try to copy, replace, delete, or move individual runtime files; that's what the distribution builder is for. As you've noted in previous posts, using distributions is the surest way to make sure your deployed apps behave as they did on the development machine.

Now, having said that, I recognize that you're in a pickle since you have problems with serial library in the 8.1 runtime engine. Since the 8.1 RTE is installed on your system, there is really no trace of the 8.0 RTE left. Your system does not have the needed files. The only "normal" way to get them back on there is to uninstall every NI application that depends on the CVI RTE (including all versions of the environment, and possibly others), uninstall the 8.1 RTE, then install CVI 8.0. You also cannot subsequently install a higher version of CVI, as it will overwrite the RTE.

In the short term, one "alternative" solution that will enable you to continue to use the CVI 8.1 environment is to replace two files in Program Files\Common Files\Merge Modules: cvirte_core.msm and cvirte.msm.  The files I've attached below contain the 8.0 versions of the "Standard Run-Time" files. If you replace the files, any distributions you build that include the "Standard Run-Time" component but does not include all the other runtime components will distribute the 8.0 files. If you choose to do this, you should back up the originals in case you ever need to distribute the 8.1 RTE again. Also, you should be aware that if any NI application installs a new version of the CVI RTE on your system, you'll be back to square one.

In the long term, the real solution to this problem is for you to fix your serial application/hardware, or for us to fix our serial library implementation. Our RTE needs to be backwards compatible to avoid these kinds of situations. I would like to work with you to solve any issue we have with our RS-232 library.  Let me know how to get in contact with you, and maybe I can send some instrumented DLLs to help debug.

Thanks.

Mert A.
National Instruments

[menchar]

Mert -

I'll just run the different CVI versions/rte's on separate PC's, no need for us to get too artful about the rte really I don't think.

I believe the serial problem is with our FPGA UartLite implementation.  It's not at all clear that there's anything "wrong" with the 8.1 serial library (other than the race condition you've mentioned), only that it has different, but probably rs-232 compliant, behavior.  I think we'll be able to move forward and use 8.1 by inserting inter-frame times by sending an extra stop bit or brute force delays between unqueued byte writes.

Being able to draw a line around the run time environment is a good thing.  In the defense business, we are often in the position of deploying applications into multiple locations, with fully controlled context - i.e., we need to be absolutetly certain that the application runs as intended.  If the runtime context isn't sharply defined, it gets harder and harder to be certain that a given application can be re-installed and up and running exactly as intended.  I had often criticized Visual Studio deployments for having weakly defined execution contexts, CVI was historically much better.

I have another question about deployment - if I include files in a distribution that aren't part of the project, can these pointers be made relative to the project directory, or are they necessarily absolute paths?

Thanks Mert, you're always responsive.

Menchar

[Mert_A.]

Menchar,

File paths are saved as absolute except for files that are added to a project. If you are distributing auxilliary files that have some association to the project, I would recommend adding them.

One thing that makes delineating the runtime engine difficult is the number of libraries we support, and the dependencies thereof.  If we came up with a list of all the files needed to call any of the function in any of the libraries we ship, it would be very large and likely very volatile. Since most users just use a much smaller set of functionality, it would be misleading to say that the whole bunch of files is required. Not to mention that many of our libraries are built on top of other shared NI components, which may change their file constituency or dependencies at any time without our knowledge. An upgrade of such a shared component could change the name or number of files included to a set different than what was shipped or installed by CVI. You can see that a complete runtime manifest would have to be a dependency tree of components along with version-specific manifests for each component. This is not something we plan on publishing or maintaining at this point. I do understand your position, though.

Mert A.
National Instruments

[menchar]

Mert -

Thanks, I didn't realize I could add a file of arbitrary type to a CVI project.  If the added files relocate with the project folder, then this likely solves the problem I was seeing.    Some of the files added only to the distribution (and not to the project) seemed to "relocate" all OK, and some didn't (?!) and would show up in red font (distribution tool couldn't find file).

Yup, it's the nature of Windows to bloat out with all of these non-obvious dependencies. 

You would not believe the grief we've been through trying to lock down application performance and configuration issues across 20+ target systems with a mix of PC types, various run time engine versions, CVI FDS on some, not on others, DLL versions, etc.    Especially when I have to guard against the SW deployment being wrongly blamed for hardware and system issues.

Menchar