Jump to content

Aristos Queue

  • Content count

  • Joined

  • Last visited

Community Reputation

1 Neutral

1 Follower

  1. Can I rename .vip files?

    Just to close this thread: Yes, you can rename VIP files after they are created. There does not appear to be anything about the name of the VIP that is encoded inside the VIP file. That turned out to not be the source of the crash, just that the name change code went in at the same time s some other code changes that I thought were "harmless". :-)
  2. Can I rename .vip files?

    I build the package as X.vip. On disk, I rename it to Y.vip. I then try to install it using VIPM. Assume neither X nor Y collide with any other package name or anything like that. Is there any reason why doing this rename could be causing LabVIEW 2014 to crash when I try to install the package? I'm sort of hoping this is some sort of known issue and not something I need to dig into on my end as a member of LV R&D. This is a package that should be straightforward to build, so I'm trying to figure out what I'm doing special with this one that might be causing the crash.
  3. I would like to build the following: Package B depends upon Package A. Package A installs first. Then Package B installs. Package B overwrites one file that Package A installed. When Package B uninstalls, it restores the file to the version that was installed by Package A. Does VIPM support this directly? If I make one package depend upon another package, are the two packages installed sequentially or does VIPM reserve the right to install them in parallel or randomly? If they do install in order, when the second uninstalls, will the original file be put back or do I need to encode that in the pre and post build VIs?
  4. A library can declare a list of friends. VIPM is currently including the friends in the list of the files that must be included in the package and is aborting the package build if the friends are not present. Missing friends will not break the library. Friends are designed to be able to be missing. Friends can be installed later, separately, but they are not required for the operation of the library. VIPM should not prevent building packages with missing friends.
  5. Crash has made package uninstallable

  6. (My current best idea is to put all the DLLs into the source and then have a post-install action that deletes the unused ones and moves the used one into the position where the code expects to find it. I haven't tested the order of mass compile vis-a-vis the post-install VI.)
  7. I find myself needing to build platform-specific packages: one for Mac, one for Linux, one for 32-bit Windows, one for 64-bit Windows. I need to change out a DLL between each of these, but I want all of them to otherwise have all the same source settings (palettes, directories, etc) and, ideally, have the same version number. Any advice on how best to build such packages?
  8. Crash has made package uninstallable

    Here's the full error report: Main Package Name: ESF - Extensible Session Framework v1.1.0.5 Package Name with Error: ESF - Extensible Session Framework v1.1.0.5 Error Message: VIPM could not install the package ni_tool_esf- . Error Code: 7 Error Source: ===============
  9. Crash has made package uninstallable

    Ok... I found that directory. There's no directory with the package name there. Any other ideas?
  10. A laundry list of problems building my new package

    I discuss the "incompatible packages" earlier. It doesn't suffice for the problem.
  11. Crash has made package uninstallable

    Where would that path be on a Mac?
  12. Midway through installing a package, my entire computer system hung. No idea what happened, but I had to kill my Mac and reboot. Now when I try to install that package again, it refuses to install, returning error code 7 but no further information. I'm guessing there are temporary files somewhere that are getting in the way of running the installer. Anyone know where those files might be so I can delete them and try again? I already wiped what I could find in the VI Package Manager "cache" directory. That didn't help.
  13. A laundry list of problems building my new package

    OK. New idea. I'm going to use the Pre-Install VI to check for the existence of the Actor Framework files and, if they already exist, return an error, which stops the install before it even happens!
  14. A laundry list of problems building my new package

    So, I tried implementing my mutual exclusion idea. I created a mutex package. I updated the AF package to use that one as a dependency. And then I tried to install the AF package. And you know what? Even though I did not have the needed dependency, VIPM installed the AF anyway! ARGH. I was really expecting it to say, "You cannot install this unless/until you find that missing dependency." Since that's not the behavior, I'm back to square one on this variations problem.
  15. A laundry list of problems building my new package

    Done. http://ideas.jki.net/topic/115121-allow-users-to-add-ctl-vis-to-the-palettes/ Now, I still need a solution to the mutual exclusion problem.

Important Information

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