Steen Schmidt Posted February 7, 2015 Report Share Posted February 7, 2015 Hi, VIPM 2014 build 1963. When building a package with licensing and adding palette to the library, this search box comes up during the build: The search doesn't find anything, and we just have to close the search box. The package seems to work ok though - what does this mean? Also, when we enable deactivation in the build spec. we aren't able to deactivate (only supported in LV 2014 and onwards). When attempting to deactivate LabVIEW tells us that the deactivation failed with the following message "Function call contains invalid arguments". NI has confirmed this and can get deactivation to work when using the TPLAT API before building the package (and thus not handle the license binding within VIPB). Anything we can do to get deactivation to work from within VIPB? Cheers, Steen Link to comment Share on other sites More sharing options...
Ashish Posted February 16, 2015 Report Share Posted February 16, 2015 Please try to mass compile the source before building the package. Let me know how it goes. Link to comment Share on other sites More sharing options...
Steen Schmidt Posted February 17, 2015 Author Report Share Posted February 17, 2015 Please try to mass compile the source before building the package. Let me know how it goes. No change after mass compile. /Steen Link to comment Share on other sites More sharing options...
Ashish Posted May 13, 2015 Report Share Posted May 13, 2015 Steen, Just trying to catch up on open items. Have you ever resolved the issue? Do you happen to have any dynamic libraries? Link to comment Share on other sites More sharing options...
David_L Posted November 2, 2016 Report Share Posted November 2, 2016 Hello JKI, I wanted to follow up on this issue as it seems that Deactivation still does not work when Binding a license in VIPM Pro. When a product uses this feature in VIPM, and a customer tries to deactivate, they are given an error "Unknown Error". This error is not given if a developer uses the "add-on Licensing Tool" inside LabVIEW and doesn't bind a license during build time. Here is how to reproduce the problem: Install TPLAT from VIPM: vipm://ni_lib_tplat License an LVLIB using TPLAT Standard Mode (Tools > Add-on Licensing Tool) Delete the licensed source code, but keep the .lf file that was created Create a VIPM build spec with the unlicensed lvlib Enable "Bind License to Library at Build Time" in "Licensing and Activation tab. Enable deactivation and use the credentials as described in your help document (http://jkisoft.com/vipm/docs/2014/index.html?turl=licensingactivation.htm) Build package Install Package on test machine Create a test license in SOLO server for the product Activate the product in LabVIEW with test license Deactivate the product in LabVIEW and receive an "UNKNOWN ERROR!" Has there been any investigation into this issue and is there any timeline for resolving it? Please let me know if you need any information from our side. Thanks for your help, David Link to comment Share on other sites More sharing options...
Featured Comment Jim Kring Posted February 23, 2018 Featured Comment Report Share Posted February 23, 2018 On 2/7/2015 at 11:36 AM, Steen Schmidt said: Also, when we enable deactivation in the build spec. we aren't able to deactivate (only supported in LV 2014 and onwards). When attempting to deactivate LabVIEW tells us that the deactivation failed with the following message "Function call contains invalid arguments". NI has confirmed this and can get deactivation to work when using the TPLAT API before building the package (and thus not handle the license binding within VIPB). Anything we can do to get deactivation to work from within VIPB? Cheers, Steen On 11/2/2016 at 1:27 PM, David_L said: I wanted to follow up on this issue as it seems that Deactivation still does not work when Binding a license in VIPM Pro. When a product uses this feature in VIPM, and a customer tries to deactivate, they are given an error "Unknown Error". This error is not given if a developer uses the "add-on Licensing Tool" inside LabVIEW and doesn't bind a license during build time. [...] Has there been any investigation into this issue and is there any timeline for resolving it? Please let me know if you need any information from our side. Thanks for your help, David Hi Steen, David. Big apologies for the long delay in resolving this issue -- I wish I had a good excuse for that, but I don't, other than it was tricky to track down the root cause and it wasn't prioritized. Fortunately, there is a simple work-around for VIPM 2014 - VIPM 2018 (see Knowledge Base: Deactivation Fails for Licensed Add-ons built with VIPM) and a fix coming in VIPM 2018f1. Link to comment Share on other sites More sharing options...
Steen Schmidt Posted February 24, 2018 Author Report Share Posted February 24, 2018 14 hours ago, Jim Kring said: Hi Steen, David. Big apologies for the long delay in resolving this issue -- I wish I had a good excuse for that, but I don't, other than it was tricky to track down the root cause and it wasn't prioritized. Fortunately, there is a simple work-around for VIPM 2014 - VIPM 2018 (see Knowledge Base: Deactivation Fails for Licensed Add-ons built with VIPM) and a fix coming in VIPM 2018f1. Perfect Jim, thanks. I'll try the workaround and keep an eye out for the fix. I'm not permitted to follow that link, is the workaround the same as Jens Gräwe suggests here?: https://support.jki.net/hc/en-us/community/posts/360000027103-Error-in-Deactivation-Infos-in-VIPM-Pro Cheers, Steen Link to comment Share on other sites More sharing options...
Jim Kring Posted February 24, 2018 Report Share Posted February 24, 2018 4 hours ago, Steen Schmidt said: Perfect Jim, thanks. I'll try the workaround and keep an eye out for the fix. I'm not permitted to follow that link, is the workaround the same as Jens Gräwe suggests here?: https://support.jki.net/hc/en-us/community/posts/360000027103-Error-in-Deactivation-Infos-in-VIPM-Pro Cheers, Steen I just fixed the Knowledge Base link, thanks. Yes, that's the work-around we're proposing. For what it's worth, the bug traced back to a cluster constant on the block diagram that had the wrong cluster order for Client ID and Server ID. It was very hard to track down, since it looked like everything was working -- the swapping of values actually happened right at a dynamic Call by Reference of a VI that has its FP controls hidden (so can't debug) and BD password protected Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.