Patrick - DMC

Update... It seems this is related to Custom Build Directories, as the same VIPC files deploying to vi.lib behave as expected (Package A contains only testA.vi and Package B only testB.vi). I of course haven't tested other directories in the options tree, but helps isolate.

Hello, I have been doing some testing for a potential deployment, and coming up with unexpected behavior building packages. This might be my basic misunderstanding, but consulting the documentation and the web I am not finding a clear answer. The scenario is this... I create VI Package A, that contains source files. I deploy VI Package A to my development PC to a custom directory (in this case Desktop/Sandbox/DMC/testpkgA). No problem. Later, I decide to build VI Package B. Source files in Package B rely on elements of VI Package A. I am using the Free Edition of VIPM so I cannot auto-scan package dependencies at build time, no problem. I go ahead an manually add a required dependency to Package B (in the VIPC file) pointing to Package A (already installed on the PC). Alright now I am ready to build, cool Package B is built and deploys to Desktop/Sandbox/DMC/testpkgB. Here's where we get the issue, Package B is deploying a copy of the VI referenced in Package A, instead of simply loading that dependency from the package already installed on disk. The result is (2) VIs named testA.vi: one located in testpkgA, and another located in testpkgB. See attached image for the full example, I have also included a snapshot of the files-installed documentation in the VIPM database directory. This seems deliberate, but goes against the concept of packages being independently updated/etc. If for example I later deploy a revision to testpkgA, by source material in testpkgB will either be in conflict or remain unchanged (as it deployed its own code copy that will not received changes). Can anyone comment on this behavior? Or, how I can deploy packages atomically with dependencies By Reference? Thanks, Patrick