Using LabView class in multiple projects

[tfritz]

Hello,

I have created a LabView class that I'd like to use in multiple projects while using source control (we use Serena for this) with the source files of the class in a centralized location (not seperately for each project as I don't want the code of the class to diverge in the different projects). Now I'm wondering what is the best way to accomplish this. I see a couple of different possibilities:

- Have the class VIs at a certain location in the repository and link to all the files from the other projects in the repository. This will mean I will have all the files in all the project folders on disk but only one archive in the repository for them as they all link to the same location. Problem: Serena cannot create links to folders, so every VI has to be linked and if the structure of the class changes or VIs, the links have to be updated in each project -> not very nice

- Have the class VIs at a certain location in the repository that will be checked out to a certain path on the local hard drive and add the class VIs to the projects from this fixed path. Problem: it's not guaranteed that the path will be the same on all computers. Some team members might check out to a different location -> bad solution

- Use a .llb file that is also in the repository and create links to it from the different projects, i.e. the source files will only exist at one location on the hard drive but in every project folder there will be an .llb-file that will come from a single archive in the repository -> actually my favourite solution. Problem: I use the VI Server to call VIs by relative path inside the class and this works differently inside the .llb, since there seems to be no folder structure anymore. If there was a good workaround for this, this might be the best solution

Does anybody have experiences on how to do something like this? Are there other possibilities to do it?

Thanks,

Tobias

[tst]

I'm not sure what the connection is that you're making between the SCC repo and the code, but I will ignore the SCC for the moment.

First, a project only holds a link to the library (a class in this case). The insides of the library are maintained by the library itself, so you can make as many changes as you like as long as you don't change the library by renaming or moving it.

Second, if you want a global location for shared code, you should place it in the <LabVIEW>\user.lib folder. Each LabVIEW version has its own copy and that means you can have different projects in different LabVIEW versions. You would probably want to build it as user.lib\_MyCompany\Reuse or something similar (the underscore is useful for not automatically including the VIs in the palette, although you might prefer to include them). Some people do the actual development inside that folder and others do the actual development as a project and only deploy the reuse code to that folder. JKI's VIPM should help you with this and there should be a free trial version.

If your question is about SCC integration, I can't help, as we use Subversion without integration.

[tfritz]

Hi,

thanks for your reply.

I think I have to make my question a little clearer. Say I have a class ClassA that uses some VIs that are in the same folder (or subfolders) as the class file. Now I put all of this in an SCC repository at the path /SCC/ClassA/. Now I have two projects that use this class and are located in the SCC repository at /SCC/Project1/ and /SCC/Project2/. Now some people might check out /SCC/ to c:/Projects, other people might check it out to d:/SCC so the absolute paths of the resulting files on the disks could be different. This makes it hard to add ClassA to both projects because on one computer the path to it would be c:/Projects/ClassA/<ClassName> on the other it would be d:/SCC/ClassA/<ClassName>. A common solution for this that we use for C++ projects is to create links inside the SCC, link the source files or a DLL inside the SCC to the /SCC/Project1/ and /SCC/Project2/ folders. This will create multiple copies of the DLL on the harddisk, one in the Project1 folder and one in the Project2 folder.

Another solution might be the one you proposed, to have the sharde files inside the <LabVIEW> folder. However there are a couple of downsides to this, as far as I can see:

- It won't work for people who don't have local admin rights (and actually having to change the files inside the "Program files" folder for development is not a good idea, imho)

- It makes it quite hard to guarantee that both the projects and the shared files are always the same version (for example if I want to build an older version of Project1 I might need an older version of the ClassA, too. If I have it all inside one project in SCC, I can just get an older label to some folder and build it. If I have the shared files in the <LabVIEW> directory, I will have to replace this. There is no way to have multiple versions (older and newer) parallely on the disk in different folders. 

Tobias

[tst]

VIPM should help with the versions issue, as it has a version for each package and should allow you to save a file which has the versions of each package needed for the specific project. You then use that file each time you want to "check out" the project and it also deploys all the packages with the specific versions you used. I can't say how this works since I haven't used it.

I would say that the easiest solution is to mandate a specific folder where the projects will be deployed or give people write access to the user.lib folders.