Hi everyone
Im doing a test project for a customer at the moment.
The project is based around TestStand 4.1 and LabVIEW 8.6 and is to be executed on a platform consisting of a pc connected to a PXI
rack with a SCXI in series. The software on the pc is a custom operator interface configured with a TestStand Base Deployment engine
license, and LabVIEW 8.6 RTE.
The LabVIEW source part consists of around a thousand VIs organized in a single project, nicely divided into grouped blocks of related code, forming small modules that can be called from TestStand.
One of these module uses functions from a .NET class library and contains a single master VI
that keeps track of all the tedious tasks the library performs.
For nearly every module in the project there's a build specification so that each module can
be linked into a single .llb file surrounded by the shared functions across llb's.
Because of the way the project is organized i've defined the build specification in such a
way that the DLL is included as 'always-included' and has it's own destination folder.
Also FYI, the whole project is under source control by means of Tortoise SVN.
Now to the weird part:
When i build the distribution that references the class library, the path reference in the
VIs doesn't seem to reflect the destination path for the library.
Using a simple ascii viewer i'm able to see that the distributed main driver VI still contains the SVN source path to the DLL.
Is this expected behaviour or did i miss some information somewhere? 🙂
This is giving me a headache at the moment since TestStand reports a broken VI whenever the
driver function is used.
I would expect that LabVIEW updated the path in the VIs referencing the DLL to wherever the
specification states the DLL to be placed, but this seems not to be the case..
Any feedback or links to information about this would be greatly appreciated!
Thanks
