10-19-2012 08:48 AM
Eric,
In LabVIEW 2012 we created a pseudopath for the Resource directory. This allows VIs to link to other files in this directory using <resource>\myfile.vi instead of relative paths as it did prior to 2011. The end result of this is that you can develop your provider code outside of the LabVIEW directory without linking problems, and therefore build them into a packge with VIPM.
Unfortunately since this was only added in 2012, your source code has to be built in 2012 or later for it to work.
David
10-22-2012 07:11 AM
David,
Thanks, that helps explain what is going on. For right now, I am trying to support back to 8.6, so I need a way to make that work.
I did get it working this morning by creating a post-install script to open all the Providers VIs that I call from API, Common, and SCC before performing my own mass compile on our provider VIs. The VIPM mass compile is then redundant, but this does work and does not take prohibitively long. I will need to replicate this mass compile pre-build on the source code, but I had done that manually for now to prove out the post-install script method.
I would also be interested in hearing from those who were successful building a provider installer with VIPM what specifically you did in pre-/post-install to make the install work.
I did find a bug in the VIPM builder that was holding me up for a while (listening VIPM guys?). I would get a librarian error towards the end of the build because my post-install VI path included the characters “\05” which showed up as an unprintable character (ENQ I assume) in the error window. Are you passing the path somewhere as a \ code string? Once I figured this out, I just changed my source code path and it fixed the problem.
Thanks for your help everyone. I am very pleased that this community has been so responsive.
Eric
10-22-2012 11:19 AM
So i'm not sure what the problem is as you describe. Was the problem specific to the mass compile during install in VIPM?
10-22-2012 12:09 PM
Michael_Aivaliotis wrote:
So i'm not sure what the problem is as you describe. Was the problem specific to the mass compile during install in VIPM?
No, this happened at the end of the build. It looked like the build completed because the package was created and I think I saw "Cleaning up" flash in the status bar, but I get the following error:
There was a problem building Product Name.
Error Details:
Code: 1
Source: Librarian Path Location.vi. File Path: "C:\Temp \Post-Install Custom Action.vi".
What you don't see is that the path is actually "C:\Temp \05\Post-Install Custom Action.vi". You can recreate this error by building a package with a post-install custom action and a folder starting with 05. I assume that starting a folder name with the hex value of any unprintable character would also reproduce the error.
Below is the snippet from the VIPM error log pertaining to that error. Hope this helps.
Eric
=========== START of VIPM Error Message ===========
An internal VIPM Error has occured on: Monday October 22, 2012 at 12:59:53 PM
= Automated Message Start =
Error 1 occurred at Librarian Path Location.vi. File Path: "C:\Temp[ENQ] \Post-Install Custom
Action.vi".
Possible reason(s):
LabVIEW: An input parameter is invalid. For example if the input is a path, the path might contain
a character not allowed by the OS such as ? or @.
=========================
NI-488: Command requires GPIB Controller to be Controller-In-Charge.
= Automated Message End =
= User Defined Message Start =
VI Package Builder Error
= User Defined Message End =
= Error Handler Call Chain Start =
VIPB_API.BuildAndPackageLibraryFromSpec[Private].vi
= Error Handler Call Chain End =
=========== END of VIPM Error Message ===========
10-29-2012 11:37 AM
TCPlomp wrote:
I have an extension to the SCC provider that I install with VIPM.
However there is an issue if the provider is calling a DLL. Since the DLL is locked it cannot be overwritten by VIPM (even if the DLL is of the same version)..
After a failed install I have to restart LabVIEW, then reinstall the provider and then re-enable the SCC provider.
Ton
I have a similar problem as Ton -- the installation of a new package fails with Error 8 when the user attempts to upgrade.
There is a workaround, since the DLL is lazy-loaded (which makes my solution a little less involved than Ton's) -- a fresh restart of LabVIEW allows installation. However this means that the user must restart LabVIEW both before and after installing the package (restart afterward required, since the Project Provider is only reloaded when LV starts).
01-25-2013 12:39 AM
Looking at this DLL locking problem: Would it be helpfull if there was an option during the package build step to specify if a LV restart is required (before or after the install)? Then VIPM would honor this during the package install process.
01-25-2013 01:12 AM
The workaround that would work for ME is the following order:
-VIPM:Select Package to install
-VIPM:Shutdown LabVIEW
-VIPM:Copy files to target location
-VIPM:Restart LabVIEW
Ton
01-25-2013 02:45 AM
If your package has a pre-install custom action, then VIPM needs to run LabVIEW to execute that custom action. So the timing of the LV shutdown nees to be just before the copy operation, but after the custom actions. So it would be more like:
-VIPM:Select Package to install
-VIPM:Start the install
-VIPM:Auto-Start LabVIEW
-VIPM:Execute pre-install Custom Actions
-VIPM:Shutdown LabVIEW
-VIPM:Copy files to target location
-VIPM:Start LabVIEW
-VIPM:Execute post-install Custom Actions
01-25-2013 10:24 AM
Michael_Aivaliotis wrote:
Looking at this DLL locking problem: Would it be helpfull if there was an option during the package build step to specify if a LV restart is required (before or after the install)? Then VIPM would honor this during the package install process.
<singing> Yes! <\singing>
01-25-2013 10:33 AM
Would it be helpfull if there was an option during the package build step to specify if a LV restart is required (before or after the install)?
Yes, I totaly agree that a restart LabVIEW option for package installation is needed.
This idea refers to the menu entries, but also would benefit provider installation.