Is it possible to determine which parts of the CVI Runtime Engine are required?

[umquat]

I've recently added some .NET controllers to allow me to use C# dlls written by a third party.

A few years ago, due to a number of reasons, instead of shipping the whole CVI runtime engine with our software, we stripped out the bits that were required to make the software run, which kept the overall package size down. Given the size of the full engine (134MB) and the fact that we probably use precious little of it, I am reluctant to add it, given that the package only occupies around 10-12MB.

I discovered yesterday that the latest version of our software doesnt work on machines other than my development machine - i.e. we are now missing other CVI stuff.

You might ask why I am not using the Distributions manager to build it. Put simply, due to US law we are prohibited from any form of encryption above a certain level being part of any software project we produce, and the installer at the time fell into this category.

So that is my dilemma. My questions are....

1) Is there any way to determine what might be missing by just knowing that the addition of .NET controllers caused the problem.

2) If I was to use the distributions manager to make a working copy of software, would it be straight forward enough to then identify what additional stuff other than my own code, has been added to make the software work, and if so where will the installer have put it. I get the impression that some stuff gets stuck in Windows\System32, but are there other locations too?

Hope you can help

Regards

Gavin Summers

[D_Biel]

You can use Dependency Walker to view the dependencies of an executable.

[umquat]

Yes I've run dependency walker on the dll that calls the .NET controller functions, and there doesnt seem to be anything missing

[Mohan]

The CVI .NET library needs two modules:

1) cvidotnet*.dll in your system or application folder.

2) NationalInstruments.CVI.Reflector assembly in your .NET Global Assembly Cache (GAC). In explorer, navigate to c:\windows\assembly to view the GAC.

We do not support distributing these files other than by using the CVI Distribution Manager.

[Jeff_P.]

Gavin,

It looks like Mohan already answered your specific question, but I can provide a couple general tips on figuring out what DLLs are being used by your application or which DLLs your application is trying to use that are missing.

1) The reason Dependency Walker didn't show these problem DLLs in your case is because the DLLs you are missing are probably loaded dynamically at run-time instead of linked statically into your application.

2) Dependency Walker has a lesser-known "profiling" feature that will track DLL dependencies at run-time and create a log of those dependencies. You could profile your application on the system where it is not working to find out what is missing. You can find details here:
http://www.dependencywalker.com/help/html/application_profiling.htm

3) The Process Explorer utility from Microsoft can show you the DLLs loaded (statically and dynamically) by a running process. You could run your application on your development system, view the DLL list in Process Explorer, sort the list by Company Name, and see which National Instruments DLLs are being used by your application. Here is a link to Process Explorer:

http://technet.microsoft.com/en-us/sysinternals/bb896653

Hopefully that information will be helpful in the future.

-Jeff

National Instruments

[umquat · Accepted solution]

You've been really helpful guys.... I'm now sorted.... The problem has primarily arisen because I've upgrade from 9 to 2010, and then 2010 SP1 during this project. I already had a local copy of the CVI.Reflector.dll in my project (9.0.248)  or something similar so that was the cause of the problem, but because I've only just started to test it on machines other than my development machine, I'd not noticed it until now.

I went looking for new copy of this file when we moved to 2010 SP1, but didnt find one. I hadnt realised it was locked up in the assembly - I think it might have been in the system32 directory before. I've now managed to get a hard copy from there and when included in the installer, the project now works on other machines.

As I said before the situation is far from idea, having to pull the bits we need out of the CVI runtime engine, but due to the way we ship software, and due to the restrictions placed on us by the US government regarding encryption issues, the full runtime engine is now too large to ship with the software, and we cant use the MSI installer as its level of encryption at least at the last assessment was too high.