distributing an application that uses componentworks++

[menchar]

I am new to using MS. 

I am going to distribute a Visual C++ application to a remote site, sending the customer a DVD.

The application is an MFC application that uses ComponentWorks++ (from Measurement Studio)  and NiDaq.

What do I need to be able to distribute this application?  Do I need to license each  target for MS?  Do I need to separately install Component Works++ on the target?

Thanks,

Menchar

[Eric_B.]

Hi Menchar,

 To create a deployment with Measurement Studio, all you have to do is create a deployment in Visual Studio and make sure the necessary merge modules are included in the deployment.  The target computer does not need any sort of deployment license because the license is embedded inside the Visual Studio project.

Information on creating a deployment with Visual Studio can be found here: http://digital.ni.com/public.nsf/websearch/ED87C183E056CAC386256DF1004E54C6?OpenDocument

Information on distributing Measurement Studio ActiveX Applications (such as the ComponentWorks components of Measurement Studio like CWGraph) and merge modules can be found here: http://digital.ni.com/public.nsf/allkb/6677098983C36F9086256CFE007F457A?OpenDocument

[menchar]

Eric -

Thank you for the reply.

As it turns out, I am using Visual Studio 6.0, so do't know if it's similar enough to the later VS version that the same info applies.  Maybe there's info in the knowledge base for VS 6.0 deployment.

Thanks again,

Menchar

[Eric_B.]

Menchar,

That is a good point.  The article I linked you to described how you would do this for Visual Studio 2003 and newer.  This other KnowledgeBase article mentions that Visual C++ 6.0 does not come with an installation building tool, but Visual Studio 6.0 Professional does: http://digital.ni.com/public.nsf/allkb/A15591DD0BCD9CDD86256D3D0050C0B9?OpenDocument .  It also mentions a utility that Microsoft released to create distributions.  If you use this, you only have to include the merge modules listed in the KnowledgeBase I linked in my previous post.

[menchar]

I'm still having some issues ...

We went ahead and used InstallShield 12.0 to create a release file (setup.exe).  We're using MS 1.0.1 so we didn't have merge modules, but rather a bunch of .ocx and .dll files in a /redist    folder that looks to be the stuff you distribute to get a ComponentWorks++ application deployed.  So we included all of those and InstallShield deployed them into the WinNT system folder.

Our app also uses NI-DAQ 6.9, and my understanding is that NI-DAQ must be run on its own installer as provided by NI.  So we didn't include any NI-DAQ stuff.

We tried testing our release on a WindowsNT virtual machine (clean machine).  We first installed NI-DAQ, then ran our app installer (setup.exe).  Install of NI-DAQ and our app appears to go OK, but when we run the application in the virtual machine it fails to start, giving us a popup that says it can't find the CVI rte!  We installed the CVI RTE just for giggles but it still died on startup.  Does NI-DAQ 6.9 use the CVI runtime engine?

My question now is, can we expect our app to start on the virtual machine?  The app is designed to run without any NI-DAQ HW present.  I am able to run it on an XP machine without any NI-DAQ HW, but that machine also has ComponentWorks++ 1.0.1 installed, VC++ 6.0 SP 5, and NI-DAQ of course as well (but no NI DAQ HW), and I didn't install the application, I just ran the executable after building it on the XP machine.  The app also runs OK on the intended WinNT 4.0 target - but the target has NI-DAQ HW & SW, all of MS 1.0.1 (including CVI), and VC++ 6.0 SP5 installed.

So I can't say I've been able to create a distribution that will install and run on a system that doesn't already have NI-DAQ, CW++ and VC++ installed.  I can't find any relevant help on the NI site for these old versions of CW++.

I'm also curious if there's a dependency between CW++ and CW?  I.e., from a VC++ application, could it have a dependency on CW (my understanding CW is for VB only).

I see what looks like a VC6 runtime of some sort in the CW /redist folder - is this an extension of the Microsoft VC runtme dll? 

Thanks for any help with this, it's funky working with these old versions - I have to support some long-lived systems deployed overseas.

Menchar

[Eric_B.]

menchar,

When installing NI software and drivers, you need to install the drivers after installing the software, so the driver installer can detect what is installed on the computer and install the necessary files.  In this instance, it sounds like the NI-DAQ installer did not install the necessary libraries to run your program.  Also, what do you mean by "died on startup"?  Did you get any error or did it just crash?

InstallShield should have pulled in the proper Measurement Studio files, so it looks like the remaining issue is with NI-DAQ.

[menchar]

Eric -

Thanks for the reply.

Yes, on a virtual machine, it's impossible to install the HW first (I think that's what you meant).  But HW first isn't the rule always - some NI installs require SW first, for example NI PCI serial boards.  I think that's because the kernel mode driver must be in place first so that the OS can assign the NI kernel driver instead of some default driver.

When we ran the app without installing NI-DAQ first, the app complained about not having an NI-PAL dll when trying to do a static load of it at app startup.    It seems NI-PAL is associated with NI-DAQ so we installed Ni-DAQ onto the VM.

The NI-DAQ install didn't complain when we ran it on the VM.  But we may have got a later version 6.9.4 onto the VM rather than the 6.9.0 version the app was built with.  The error was a generic windows popup saying app failed to initialize properly.  We tried reinstalling NI-DAQ 6.9.0 on the VM, and it appeared to work, but I'm wondering if the 6.9 install just shined us on 'cause it saw 6.9.4 already there and didn't do anything.

Do you know where we might have picked up the CVI RTE dependency?  Does Ni-DAQ use the CVI RTE?

In the past, I've had trouble too with the NI-MAX, if it's present (and it's virtually impossible to prevent its install) when using the CVI distribution editor, you wind up with dependencies on almost anything under the sun from NI that's ever been on the build machine at some point in time, even if you don't reference it in the app you're distributing.   I'm wondering if the same sort of pathological behavior affects InstallShield builds too.

And I can find no guidance on what should be included in the release from the MS 1.0.1 distribution pieces - I guess we could feed the various .dll's and .ocx's into InstallShield one at a time to see what's really needed.  I would think it's not an error to include everything?

Thanks for any info you can provide,

Menchar

[Jervin Justin]

Hi menchar,

What Eric was referring to had nothing to do with installing the Hardware, but rather the drivers.

Typically the order of installation is to install the Development Environment (LabVIEW/CVI/Visual Studio) first and then the driver after. The reason for this is because the driver installers typically check to see which IDE/ADEs (Integrated/Application Development Environment) are installed on the machine so that it can integrate properly with those environments.

Regarding the installation of NI-DAQ 6.9, typically if you have a newer version of a driver installed (as you did in your case), the installer will not install anything and one of the info screens will tell you that nothing will be installed. If you simply clicked the Next button several times, you might have missed this, and it would have brought you to the final "Installation Complete" dialog.

[menchar]

Thanks for the response.

I still cannot successfully distribute an application with ComponentWorks 1.0.1 despite our best efforts.

We include everything in the /redist folder that comes with CW 1.0.1 and put it in the system folder on the WinNT 4.0 target.  The application itself runs, but exhibits erroneous behavior.  If I simply copy the executable on top of the previous version (i.e. don't use a distribution and don't try to distribute/install redistributable CW++ stuff), the application runs without error, using CW++ pieces that are there due to a previous full install of MS 1.0.1. 

It seems I can't get any insight from the MS 1.0.1 docs nor does anybody here seem to remember much about it.  

Menchar

[menchar]

To at least partially answer some of my questions:

I think some of the trouble I'm seeing is that the target didn't have NI-VISA runtime installed on it.  I would have thought NI-VISA would install with Ni-DAQ 6.9 but maybe not?

NI-VISA 2.0, the version of the VISA runtime we know is on the systems where the app does successfully run, does have a dependency on the CVI RTE.  

All of our other systems seem to have CVI installed, and so NI-VISA would be there by virtue of CVI if nothing else. 

I see I can download NI-VISA run time 2.0.1 - do I have to buy and feed it a deployment license for my VM target despite having installed NI-DAQ?  Maybe NI-VISA looks around for other NI components before it will run?

I guess I'll try downloading NI-VISA, running it on its own installer, and seeing if that allows the app to start up and run on the VM.

So how does IVI get on a system - is that a separate installer too?

Menchar, thanks for the help.

Menchar