Jump to content

Recommended Posts

I recently discovered a bug or perhaps an "added feature" not sure which :) so I posted it here. Here is my sad story, I am telling this sad tale in the hopes it will save someone from all the grief I suffered.

First I will explain what I did, then what happened, why it happened and lastly how to recover.

What I did, I built an installer for an application, "My Application" that included several additional NI installers (MAX, NI 488.2, VISA ....) after the build was complete a file, lets call it "setup.exe" was created to install the application. I copied the installer onto a network drive, and then went to a different LabView development machine ( Dev 2), and ran "setup.exe", from the network drive, to install "MY Application" on that machine. The install went fine and the application worked as expected.

What happened, several days later I was building an Installer for a different application (Setup2.exe) on Dev 2, this Installer also included some NI installers. Here is where it gets fun :wacko: , during the build a dialog box popped up stating "Unable to locate the installer source for 'Setup' distrubution. Locate the distribution and try again." with a path control pointing to the "Setup.exe" located on my network drive. I had deleted "Setup.exe"from network drive so it failed the build. At this point I was confused as to why the build for "Setup2.exe" was referencing "Setup.exe", but I thougt ok , I will put "Setup.exe" back on the network drive , and try to build "Setup2.exe" again. Second try for "Setup2.exe" still popped up the same dialog, and failed. Looking at the details of the dialog that is displayed after a failed build I discovered a line staing it could not find Setup, but found somthing close. Two other development machines that had "My Application" Installed on them exhibited the same failure mode when trying to build a new installer with additional NI installers included.

Why it happened, whenever you include an additional NI installer in a build it needs the installation source for the NI 'package' you are trying to include with your installer. By default it looks in the location that the 'package' was installed onto your development machine from, but you can point to another location for the 'package' source if it is not located in the same place, but it must be the same version as the package that is installed on your machine. I guess I did not realize this prior to this experince because I have a VLA, and I always have the drive that I installed from mapped on my development machines. In retrospect it makes sense. So, what was happening was the Installation of "My Application" on Dev2 was installing newer versions of some of the NI 'packages', so from Dev2's perspective the source for those packages was installed from "Setup.exe". What this ment is whenever I tried to build a new installer on Dev2 that included NI packages that were installed from 'Setup.exe' it needed to find the source for those packages in "setup.exe". I guess that makes sense to me now, but what doesn't make sense is it appears it needs not only find the same version of the source, but it needs to reside in a file called "setup.exe" and the version of setup.exe needs to be the same version it was when the source for the package was installed from it.

How to recover, the first thing I tried sense I nolonger had a copy of the build for "setup.exe" that was used to install "My Application", was to uninstall Labview and re-install LabView. My thought was that this would change the location of the source for NI packages back to the VLA server, however it still wanted "Setup.exe". I had had enough at this point so I removed everthing NI first through ADD/Remove programs, than MSIBlast.exe. I reinstalled Labview, tried to create a Installer with NI packages, and still it wanted "setup.exe" :angry: At this point I was ready to cancel my trip to Austin next week, and swear off LabView for ever :laugh: . Then my collegue decided to search the registry for "<path to setup.exe>" we found an entry that referenced NI 488.2 to "<path to setup.exe>" we deleted the entry and all our problems were solved. We went to the other 2 development machines sereched the regestry for "<path to setup.exe>" and found 30 or so refernces of NI packages pointing to "My Application" we deleted all entries, and like magic problem solved. :thumbup:

In conclusion be very careful when you install a Labview built application on a development machine, and if you should find yourself in a similar situation search the regestry for "<path to setup.exe>", and delete all references.

Link to comment
In conclusion be very careful when you install a Labview built application on a development machine, and if you should find yourself in a similar situation search the regestry for "<path to setup.exe>", and delete all references.

Thanks,

I have an issue where the builder is looking for the february device drivers disc for some reason, reinstalling the may discs didn't help.

This is very helpfull, but could you give a pointer to where this registry entry is? :yes:

Ton

Link to comment

Thanks,

I have an issue where the builder is looking for the february device drivers disc for some reason, reinstalling the may discs didn't help.

This is very helpfull, but could you give a pointer to where this registry entry is? :yes:

Ton [/quote

Use the find function of your regestry and put the path from which your device drivers were installed and substitute May 2006 with Feb2006 in the path. For examble may path was Z:\Public\NILabview\Ver 8\May2006\Device Drivers for Data Acq Instrment Cont and Vision\Disk1\products\gpib\driver\ So if I want to find were Feb is being used I would search for Z:\Public\NILabview\Ver 8\Feb2006. The word is Installersource. Be carefull it is possible if you did not install all the same packages in your May updates as in Febuary the source for the package you are trying to include could truely have been installed from Feb. Look at the name of the packages you find in your registry that have come from Feb and determine if you truly did install it from May if so try chaning the path, if not reinstall that package from May. Good luck, be careful.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.