Licensing tool breaking library

[amcelroy]

Howdy,

I'm trying to use the 3rd party license tool to package a custom library for distribution on the NI Network.  Unforunately, there are some issues when using the tool.  A license has already been defined for the product on the SOLO server.  Once the library is licensed, a report pops up that says maybe 7 of the 30 libraries have conflicts.  When I open up my lvproj file, it lists the original library and the licensed library and a whole lot of linking errors as a result.  Why is the licensing process causing the linking errors?

In summary:

1.) License library through SOLO server with no linking errors

2.) Linking errors occur as an output of the licensing process

3.) Opening up the .lvproj shows 2 conflicting libraries, the original and the licensed

Thanks for any help,

Austin

[David_L]

Hi Austin,

You mentioned that "7 of 30 libraries have conflicts".  Is it safe to assume that you have multiple libraries in your project, but only a subset of these are being licensed while the others are unlicensed?  If this is the case, I think I know why you are getting linking errors.  The licensing process copies the lvlib that you are licensing and it's member VIs to another directory (by default it's <source directory>\licensed.  However this ONLY copies the lvlib and VIs that were licensed.  Any other VIs, libraries or other files that link to these licensed VIs remain in their current location.  Because the other files are not copied/moved when you open them they see two different libraries in memory and don't know which ones to pick.

For a complex project like this, I would suggest using a source distribution to separate your "source" code from your "distributable" code.  Then you can use the add-on licensing tool to license the distributable lvlib in place (i.e. save the output lvlib to the same path as your input lvlib) and all the linking problems should go away. 

Let me know if this helps clear things up,

David

[amcelroy]

Hi David,

Yes, your assumption is correct.  I've only one library that needs protection, and all the other VIs in the project reference this library.  Also correct, a new license folder with the licensed library and VIs in the that library are created. 

The Add-on Licensing tool does not seem to allow for the directory of the input library to be the a valid directory for the output library.  Along the same lines, I've tried licensing the library and then copying the licensed library and licensed VIs and just pasting them over the existing ones (in a copy of the project so as not to destroy the originals).  This does not work, as there are linking errors referencing VIs that are not in the correct spot.  I'd have to go back and hand correct the linking errors for a lot of VIs, which would be nice to avoid.

Thanks,

Austin

[wirebirdlabs]

Perhaps another helpful resource is Aristos Queue's Recipie For Component Development With PPLs or DLLs -- this outlines a process to solve a separate problem, but conceptually these two issues seem to have a lot in common.

[David_L]

The Add-on Licensing tool does not seem to allow for the directory of the input library to be the a valid directory for the output library.

Hrmm, good point, I forgot about this factoid.

Along the same lines, I've tried licensing the library and then copying the licensed library and licensed VIs and just pasting them over the existing ones (in a copy of the project so as not to destroy the originals).

How about trying the opposite: 

1) From original project license the library and save it to the "\licensed" directory.

2) Copy everything from the original directory into the new licensed directory except the library and VIs that you just licensed. 

3) Close the original project and open the new project

I know this is not an ideal workflow, but I've tested it here and it seems to work for me.  I have a personal goal to improve the licensing process for more complex products such as this by creating a special tool (e.g. new build spec) or improving the existing wizard (harder to do in the short term).  If you or anyone else has any suggestions on your "ideal" process for licensing, I am all ears as this problem is becoming more and more common.

[David_L]

Thanks for the tip, Jack.  I'll have to read through the long discussion to see if I can learn anything to improve the licensing use-case.

[amcelroy]

Thanks Jack, I'll check it out.

Just another updated, I've added ALL the VIs in the lvproj to the library and try using the license manager tool, and it still spits out linking errors.  Also, when an error occurs using the 3rd party tool, it doesn't allow for interaction with the errors window.  Must be a bug.

Ok, so the problem appears solved if adding ALL files in a project to a library.  There were to VIs that were in the library, but they were showing up in the depencies instead.  Just dragging and dropping them into the correct virtual folder inside the library seems to have cleared up that particular set of errors. 

To David:

From my end, I've spent as much time coding up this project as learning the licensing aspect of it all   It would be awesome to take a project, right click on a library, license the library which would copy the current project to another folder and license the library, and then pop open VI Package Manager to finish things up. 

Will follow-up and try fixing the dependency issue with only the files needed in the library in the library instead of everything.

Austin

[Roso]

Hi all,

An alternative suggestion is to create the source distribution first, then license the source code library and tell the tool to copy the licensed library to the source distribution folder.  The tool will overwrite the distribution library and the linking should be intact.  We tested this idea here and it worked for our simple project.  If you have problems with that, let us know.

[David_L]

Just another updated, I've added ALL the VIs in the lvproj to the library and try using the license manager tool, and it still spits out linking errors.  Also, when an error occurs using the 3rd party tool, it doesn't allow for interaction with the errors window.  Must be a bug.

Ok, so the problem appears solved if adding ALL files in a project to a library.  There were to VIs that were in the library, but they were showing up in the depencies instead.  Just dragging and dropping them into the correct virtual folder inside the library seems to have cleared up that particular set of errors. 

I would suggest against adding all the files to the library to be licensed.  The reason is that licensing prevents users from viewing the block diagram in order to protect IP.  Examples on the other hand should be open and viewable to the customer during evaluation so they know how to use the API.  Having the examples open and viewable is actually a requirement for Compatible With LabVIEW if you plan on submitting to the LabVIEW Tools Network.

I would try out Roso's suggestion below as it might be a easier alternative without breaking the linking.  Just make sure to not open the Licensed and the un-licensed versions of the code at the same time.

From my end, I've spent as much time coding up this project as learning the licensing aspect of it all   It would be awesome to take a project, right click on a library, license the library which would copy the current project to another folder and license the library, and then pop open VI Package Manager to finish things up. 

This definitely sounds like a good solution.  I believe it might require a VIPM build spec from JKI.  If the licensing had a build spec, and VIPM had a build spec, you could daisy chain them all to have a one click build process.

Alternately, if you use VIPM Pro, there is an option to bind the library with licensing at package build time, which takes all of these problems out of the picture.  That is really the best experience if you are using licensing and packages together. 

[vishots.com]

There is a video on the JKI support site that explains how to do what you want with a single click. You can have one LVLIB that's licensed and one that is not. This should not be a problem when using dynamic binding with VIPM. Hope this helps.

How to use Licensing and Activation in Your VI Packages