DLL files get not distributed

[Greg_NTI]

Hello,

in my application distribution, I have added two DLL files which are not in the DLL-Dependency of the project, because they are called by a third DLL. Therefore I manually added the two files in my installer setup. They are also listed in my project workspace and should get copied into the application directory.

For some reasons, the two files sometimes get not copied to the target machine. This seems to especially true when installation replaces an older version which did not have these files. Uninstalling the software via " System Control --> Software"  before running the distribution fixes the problem, but is not acceptable for customers. The rest of the application (with many other files incl. DLL's) installes well.

Does anybody know what could cause this behaviour and how I can fix this?

Best Regards,

Greg

[Mert_A.]

Hi Greg,

Which version of CVI are you using to build the distributions?  In the case where a newer distribution replaces an older one (that did not include the extra DLLs), what are the version numbers of the two distribution kits?  Are you certain that other files in the distribution were updated/replaced properly, or is it possible that the "install" actually did nothing?

If it is not too difficult to reproduce the problem, I would suggest running the installer from the command line and passing it a flag to create a log file:

setup.exe /log <filename>

If you can post a log file, it should help us understand what is happening.

Mert A.
National Instruments

[Greg_NTI]

Hello Mert,

thanks for your reply. I'm using CVI 8.0.1.
You were right, I seem to struggle with the general behaviour of the installerm, - not any exceptions. Right now, I have identified two cases which seem strange to me. Please have a look at them.

CASE A)
I'm running the installer pointing to the default directory: "C:\Program Files\MyApp\" - that install runs nicely
I then run the same installer again, but pointing to a different directory, e.g. "C:\Program Files\MyAppII\"
--> I get the installer summary message: "No software will be installed or removed"
--> I would expect that the app gets installed into the other directory too.

CASE B)
I'm running the installer pointing to the default directory: "C:\Program Files\MyApp\" - that install runs nicely
I then delete or rename a few installed files, including the executable of the application.
I'm running the installer pointing to the default directory: "C:\Program Files\MyApp\"
--> I get the installer summary message: "No software will be installed or removed"
--> I would expect that the missing files of the app get installed.

Please let me know if these two cases are expected behaviour, and if yes why.

Thanks
Greg

[jlaney]

Hello,

First let me explain something about how installers track things.  First there are the features which are high level groups of many files and this is the first thing that the installer looks at to see whether they have already been installed or need to be upgraded.  Then there are components and these are either single files or groups of similar files in the same directory,  These do not get looked at unless you are doing something that has already made it past the feature check, these can include repairing an install, upgrading from an older version, or even using shared components between 2 different installers.

So now with that information let me answer these questions.

Case A.  The installer system sees that the software is already on the system because all the features are the same it stops and considers this a no operation necessary.  If you update the version number and rebuild the installer then the system will see it as an upgrade and you will be able to move the installation.  I do not see moving an installation to another directory as something that any installation system allows.  Typically you must uninstall and reinstall to a new location for anything that you have installed and want to move to another directory.

Case B.  This is a special case that is not done through simply rerunning the installer.  Again the installer see that all the features are installed and therefore does not go any further to try and fix things.  Since this is a case that was thought of, there is a "repair" option in Add/Remove Programs in the control panel for you installation that does exactly what you ask.  It goes to each component and checks that it is installed correctly and if it is not then it reinstalls that component.

I hope this answered your questions.  Let us know if you are having any more trouble.

-Jeff
NI

[Greg_NTI]

Hello Jeff,
 
thanks for your reply.
Looking at your explanation, I assume that the DLL's I add manually to the list of files to deploy are treated as "components"  Is there any way to configure the deployment so that the installer treat them as "high level groups" and replaces/overwrites them with "no questions asked" ?

I would also not move an installation or rename the directory. However, - people sometimes do such things, - and unfortunately one of them is a customer of ours.

The "Repair" option in the "Add/Remove" section would make sense, but unfortunately all apps made with CVI show only up with the "Remove" button.

Thanks for your help.
Greg

[Greg_NTI]

Hello,

the problem unfortunately occured again, and I missed to activate the installer log features.
However, I compared earlier versions of my installer configuration (which did not seem to have that problem), and found a
difference in the definitions of the dll in question:

Old version (seemed to work): 
<simpleFile fileID="414" sourcePath="c:\CVIPROJ\RT Speaker NEW\qserlib.dll"

targetDir="100" readonly="false" hidden="false" system="false" regActiveX="false" runAfterInstall="false" runAfterInstallStyle="IMMEDIATELY_RESUME_INSTALL" cmdLineArgs=""/>

New version , causing problem:
<simpleFile fileID="414" sourcePath="c:\CVIPROJ\RT Speaker NEW\qserlib.dll" relSourcePath="qserlib.dll" relSourceBase="0" targetDir="100" readonly="false" hidden="false" system="false" regActiveX="false" runAfterInstall="false" runAfterInstallStyle="IMMEDIATELY_RESUME_INSTALL" cmdLineArgs=""/>

When I look at the old and new version in the installer setup GUI, I do not see any difference. The dll was and is supposed to get installed to the application directory.
Can somebody tell me please what the "relSourcePath="qserlib.dll" relSourceBase="0" " parameters do and how I got them?

Thanks
Greg

[Mert_A.]

Greg,

The contents of the .cds file may change from release to release as we make implementation changes.  This is nothing to worry about.  This particular addition allows files (that are found in your project tree) to be tracked relative to the project directory, so that you may copy/move your entire project from one place to another and still have the files picked up from the right place.  If the files cannot be found relatively, then CVI falls back on the absolute path.

If you can successfully build your distribution, then all the files you specified are correctly being found and built in.  From what you said earlier, I understood that your DLL files were not actually being "left out" of the install, but rather the installation hadn't actually run at all.  Did I misunderstand the situation?

Mert A.
National Instruments

[jlaney]

Hello Greg,

First, there is no way to make files a higher up construct in MSI.

I just went and talked to our installer architecture team and found that there is currently not a way to repair a customer built installer.  I had this added to the list of things that should be fixed.  I am sorry I assumed incorrectly that a customer built installer would behave closer to one of our internal built installers.

About your CASE A where you want the customer to be able to install in multiple location.  This is an impossibility with the installer because we track the entire installer for easy uninstall.  If you were to allow this you would then have the converse issue of what to uninstall when the customer wants to remove the files.  The uninstaller would only know about the last one installed and thus leave all the other files on the system.  This is something I have have not seen any installer allow, such as trying to do this with Office, WinAmp or Firefox installers is disallowed. What I suggest is try to find a way around this in the application itself. I do not know your exact circumstances but we have had to architect similar things in our installers/applications where there is a default install to some common location on the system.  Then the application gives the customer the option of making separate copies to different locations on the system as well as removing them through some type of manager application.

There is a way to do all this in an installation scenario with custom actions but that goes way beyond the scope of an installer tool built into an ADE such as CVI. You can purchase a tool or get an open source solution specifically for creating installers that con allow you to do almost anything that you wish.  The issue with that approach is that you have to learn a lot about the installer technology (MSI) and implement your specific solution for your install.

Regards,
Jeff
NI