Package installation error

[JasonW]

I have encountered a problem trying to install a package of VIs with VI package manager. The package is a set of re-use VIs that is placed in the user.lib folder. I built the package using the OpenG package builder. When I tried to install the package I received the following error message:

 

 

The machine is a PC running Windows XP 32-bit. My LabVIEW version is 2009. The VI package manager version is 3.0 (build 1280) Community Edition. Other packages (i.e. the JKI tester tool update) installed just fine before I tried my package. I previously built an OpenG package for a JKI RCF plugin distributed with in the company that worked well. I have tried modifying the package setup even down to a single file and I get the same problem. It would appear that there is a problem with the package I have built but I am at a loss as to what the problem can be.

 

Thanks

 

Jason

[Jim Kring]

Hi Jason,

 

I'm sorry to hear about the trouble. The "alpha" in "1.0-alpha-5" looks like it might be the culprit. This doesn't seem to be a naming convention that VIPM would like.

 

Can you try renaming your package "1.0alpha-5" (remove the hyphen between "1.0" and "alpha")?

 

Also if that doesn't work, please post your latest error log file, located here:

 

C:\Documents and Settings\All Users\Application Data\JKI\VIPM\error

 

Thanks,

 

-Jim

 

P.S. I'm glad that you've downloaded VI Tester 1.1.1. Are you using it, or did you just download it?

[JasonW]

Hi Jason,

 

I'm sorry to hear about the trouble. The "alpha" in "1.0-alpha-5" looks like it might be the culprit. This doesn't seem to be a naming convention that VIPM would like.

 

Can you try renaming your package "1.0alpha-5" (remove the hyphen between "1.0" and "alpha")?

 

Also if that doesn't work, please post your latest error log file, located here:

 

C:\Documents and Settings\All Users\Application Data\JKI\VIPM\error

 

Thanks,

 

-Jim

 

Thanks I'll try that this afternoon. If not I will do as you ask.

 

P.S. I'm glad that you've downloaded VI Tester 1.1.1. Are you using it, or did you just download it?

Using it some. Still trying to wrap my head around the idea and the best way to identify test cases. I think it will be a useful tool once I understand the best way to use it in my applications. Right now I am working in unit testing into the re-use library we are building as a starting point.

 

Thanks

Jason

[Jim Kring]

Thanks I'll try that this afternoon. If not I will do as you ask.

Using it some. Still trying to wrap my head around the idea and the best way to identify test cases. I think it will be a useful tool once I understand the best way to use it in my applications. Right now I am working in unit testing into the re-use library we are building as a starting point.

 

Thanks

Jason

 

Hey Jason,

 

Cool, good luck with the package build.

 

That's great that you're starting to use VI Tester a little. It's REALLY useful for unit testing a re-use library. At JKI, we have actually integrated VI Tester with VIPM -- we have a post-build hook VI that runs all the unit tests for the VI Package sources programmatically (using the VI Tester API), and aborts the build (by raising an error inside the build hook) if any unit test fails. This guarantees that all unit tests pass before we can build a package and share the code with our team.

 

Cheers,

[JasonW]

That's great that you're starting to use VI Tester a little. It's REALLY useful for unit testing a re-use library. At JKI, we have actually integrated VI Tester with VIPM -- we have a post-build hook VI that runs all the unit tests for the VI Package sources programmatically (using the VI Tester API), and aborts the build (by raising an error inside the build hook) if any unit test fails. This guarantees that all unit tests pass before we can build a package and share the code with our team.

 

 

That's exactly what we've talked about doing. We have even discussed using a similar approach to test critical elements (those that can be anyway) of standard builds.

[JasonW]

 

Okay it worked. I finally got the package to install. I changed the name of the package like you suggested but that did not help the problem. The package still would not install, nor would it appear in my package listing for package manager. I then built another iteration of the RCF package I had made previously and it installed just fine. On a whim, I used a file diff view to compare the contents of the two OpenG Package Build files (*.ogpb) just to see what the differences were. Looking those I noticed that, besides the file names and number of files, on difference was that in the failing package I had included a parameter that restricted the OS to windows XP. I did it by typing it in not by selecting a value. I thought that perhaps I had entered this information wrong so I deleted the OS requirement. I rebuilt the package and it installed just fine. I have already done a quick mod to the package, built and installed the package again. No problems. Is there any way that the error that was reported could have been related to the OS restriction?

 

Also, after I changed the file name and tried to install the package, I looked in the folder you specified for an error file and there was no error file created. There were others from previous days, mostly with errors about LabVIEW not connecting when installing a file.

 

Thanks for the help!

 

Jason

[Jim Kring]

Hi Jason,

 

You're welcome. I'm happy to hear that you're up and running.

 

Without an error log or copies of your "bad" package, it's hard to know exactly what was the problem.

 

When you renamed the package, did you just rename the file or did you also rename it in the spec file (that was used to build the package)? The reason I ask, is that VIPM pays no attention to the actual file name -- it only uses the package name and version in the spec file inside the package.

 

It could have been an issue with the use of "Windows XP" -- VIPM uses the name "Windows NT" for Windows XP (and Windows Vista/7), since that's how LabVIEW (the Application OS.Name property) reports it .

 

BTW, this problem would have never happened if you used VIPM Professional to build your package

 

Cheers,