Licensing tool breaking library

[amcelroy]

Hey Michael,

That is a good answer and helpful, but I'm still having troubles.  I've downloaded the free version of Protection PLUS (before shelling out $350 for a license) and generated a key using the example here: https://decibel.ni.com/content/docs/DOC-13906.  Now I have a .lf file that just has "password" as the password.

Next, go to VIPM Pro, add the library to be protected and the .lf created above, and click "Bind License to library at build time." The "License file password" is "password", and the Activation Method and Library Protection are as in the video.

VIPM builds and installs with no errors.  When restarting Labview, there is no indication that the add-on registered, and when adding VIs from the custom palette, there is no restriction to the block diagram on the ones that should be protected.

I'm missing something and it is really frustrating! 

I appriciate all the help y'all have given so far and will keep at it.

Austin

[vishots.com]

Sorry you're having problems.

What version of LabVIEW are you using?

A few things:

• This process assumes that the library is not already licensed, so please check that first.
• Make sure you specify the path to the LVLIB and LF file in VIPM as well.
• One thing to watch out for is trying to activate or install a package that is already activated on the system. Just to be sure, create a fresh license file and try again

If you want, you can contact VIPM support offline and I can walk you through the process together.

[amcelroy]

Hey Michael,

Labview 2012, and in response to the bullet points:

• Correct, this is a fresh .lvlib from an SVN
• Correct, the .lf file is being pointed to in the "License File Path" box and the fresh lvlib is being pointed to in the "Licensed library file path" in VI Package Builer Pro
• Good to know, but I've not been able to get anything to activate, what with the problems with linking errors using the NI 3rd party tool and the issues now.

Reckon we can hash out these issues here if folks don't mind.  Maybe it will help out some others since VIPM might be getting pretty popular these days

Thanks,

Austin

[vishots.com]

What I meant by taking it offline, was that we could connect with join.me or other remote software and I could do a one on one with you. It would speed up the resolution and then report back here with findings. Still offering this if you want.

Another thought: Make sure the LF file and LVLIB is indeed located on disk at the path you specified in the Licensing & Activation page of VIPM. There's a reported bug which we're fixing where VIPM does not report an error if the paths specified in those fields point to nonexisting files during build.

[amcelroy]

Sure, let's setup a time remote desktop or share screens and I can write up the results afterwards.  I'll email JKI support and we can go from there.

The files both definately exist.

Hold on folks, answer is coming up soon!

Austin

[David_L]

I'd be interested if you guys find anything interesting in your debugging session.  Here are a few things to consider:

1)  Which version of Windows are you using? If Windows XP, we've seen some issues with XP pre-SP1 with licensing due to the signature of the licensing DLL not being recognized as valid in the older OS.  There is a workaround I can dig up if you can't upgrade to XP SP1 or later and you think this applies.

2)  If Windows Vista or later, keep in mind problems with UAC  Licensing for a toolkit writes registry entries and requires administrative rights during installation (when RegisterAddon.exe is called). 

I'm away from my office most of the day today, but I'll try to check in with the progress periodically if the community can't come to the rescue.  Thanks to Michael and Jack for the extra help here!

David

[RDR]

Issue 1 that David refers to has to do with the certificate store or root certificates being out of date on an older XP system - there is a regular update distributed to update the list of trusted authorities and we encountered an older system where the service used to digitally sign the Protection Plus DLLs was not a trusted authority.  You can confirm this by looking at the properties of the Protection Plus DLLs for the signature status:

The status under 'Digital Signature Information' will not indicate the "The digital signature is OK." when the signature cannot be confirmed.  The reason this affects the license mechanism in LabVIEW is we ignore the DLL calls and the licensing mechanism is halted to protect licensed code on machines where the we believe a person is attempting to hack the licensing scheme by tampering with the DLLs.

I found a somewhat recent update for XP Root Certificates from Microsoft here:

http://www.microsoft.com/en-us/download/details.aspx?id=35945

[amcelroy]

This is all under Windows 7 x64.  There is a custom DLL that is included in the project Labview has been ok with it every step of the way so far. 

I'll also be out of the office today, but hopefully tomorrow Michael and I can figure it out.  Probably something stupidly minor on my end.  Will let y'all know.

[vishots.com · Accepted solution]

So Austin and I spent an hour and half debugging this issue and have found the problem.

It turns out that there is a certain configuration that VIPM dynamic license binding doesn't like. Specifically:

1. Having a Company name defined with a comma. For example: "mycompany, inc"
2. Specifying a Toolkit VIs Destination as an LLB.

When we removed the comma and set a target destination for the VIs to be a directory instead of an LLB. Everything worked as indicated in the video I posted here.

I'm investigating this to find the source of the problem and hopefully fix it in the next release of VIPM.

Thanks to Austin for allowing me to help and being so patient with this.

Edit-Follow up:

• I tried to reproduce issue #1 but could not cause it to fail. So I'm not sure that the comma in the company name can be confirmed.
• Issue #2 is valid. The reason why it was failing is because the licensed LVLIB was being placed inside of an LLB. Yes, this is possible but we are not handling this correctly in VIPM. I'm not sure if the licensing and activation toolkit supports this scenario in practice, so probably VIPM needs to warn about this and not fix it. More investigation is required.

[amcelroy]

Hey Michael,

I had another issues later on, but solved it by deleting the license file from the C:\ProgramData\National Instruments\Partners directory to fix the issue.

Austin