Version Control

[cy...]

hello forum

what do you think about a "feature" where developers can enforce version control on applications deployed into end-user systems? it may sound something like some feature of a certain OS, but it may be beneficial in a way or two...

the most obvious being for version enforcement, some members may not like this, but often time newer versions of application are developed to address certain issues of the previous version, and it would be pointless if the end user kept sticking to the old version for certain feature they may have grown to like

it can also be extended to subscription based or trial version deployments, a more friendly way for developers to present their systems for customers for in-situ system trial

one way to deploy this feature, is to minimally trace the execution instances of the RTE in deployed systems, across newer and older version, log them for follow-up actions, that can range from friendly popup reminders for update to application execution prevention.

what do you think?

[AristosQueue (NI)]

The idea is a bit vague for me to comment on much. Would the (still relatively new) facilities of the NI Package Manager cover this use case? NIPM can monitor for new versions and encourage upgrades. Or are you talking something that would be part of the built application to detect and do such upgrades? I can see how that would be valuable for systems without NIPM installed.

[cy...]

Hi AQ, 

let say in a case where application A was build many years back and recent development has given birth to application B, which serve the same function as A but enforces new policies in its execution. Developer would want to ensure only application B is in service throughout the organization, can the package manager achieve that?

can it serve like a local license manager that can log application usage statistics and control the execution of application (inclusive of previously built) through RTE control

1. if listed in white list, allow execution 
2. if unlisted, temporarily allow and logged in grey list to sync with server the next time it connects network, where it will be investigated and defined white, grey or black
3. if listed in blacklist, upon the next time the system is synced, execution will be block permanently 

[AristosQueue (NI)]

I *think* NI has all the parts you need to build an application that does this.

I think you want to investigate this:

NI License Manager Third-Party SDK

This is an API to let you do the same licensing checks that NI uses for its own products. You add that to your application to make an app able to revoke its functionality through a license server. It does have one severe restriction: your application or library must be sold through the LabVIEW Tools Network, not through any other portal. That's a restriction placed on NI by the vendor (FlexLM), so it isn't something we can relax.

If you want a licensing solution to use outside of the LV Tools Network, NI offers Third-Party Licensing and Activation Toolkit (TPLAT) and licensing your own server with Concept Soft.... That provides an "easy" option that is just go/no go. If you need more fine grain API control, use this. This mechanism is "baked into" LabVIEW 20xx but will not be carried into LabVIEW NXG. You can still use the those tools in NXG (provided the company provides an API), but there are many different application protection tools on the market now, and you can choose the one you like. In particular, check out BLT if your use case is for internal clients.

Going forward into NXG, the only licensing support that NI will bake in is the FlexLM licensing for distro through the Tools Network. This is both to encourage a single licensing pattern for toolkits and to not put our thumb on the scale when you are evaluating application licensing tools.

A note from another developer here at NI: In any case, if they want to sell through the Tools Network I recommend directing them to the LV Tools Network team for support (labviewtoolsnetwork@ni.com). If they want to sell outside of the Tools Network, direct them to the Concept Software company who creates the licensing tech behind Instant Protection PLUS and TPLAT.

As for NIPM: NIPM can do regular checks for upgrades of the same package. I don't think it allows for replacement by a different package. But you could publish a new version of Application A that is nothing more than a dialog box that says, "This app is no longer supported. Click here to install App B." User would have the option to install the App A upgrade, and that would guide them to App B. I do not believe there's any ability to *force* an upgrade. But if you added the aforementioned license code to your application, that could point the users to install App B.

[cy...]

Thanks AQ for the tips 🙂

having a licensing control is good, but still missing a function of version enforcement. is the NIPM running as a background process? is there any usable and accessible statistics that perhaps be applicable for this cause? or any other background monitors that can possibly be work-around-ed with?

perhaps would need to implement a traceable record system, where <something> like a token can be checked out for application execution, and to record the details of the transaction and synchronize its records with the server once it is returned. data without the transaction records will be rejected without any exceptions. still can't prevent execution of the expired, but would render its output pretty much useless.

[AristosQueue (NI)]

Licensing control is something you build into your app. Your app would check the license when it starts up and then refuse to do anything useful if the license check fails. That's the enforcement mechanism. Anything external to the app can be turned off by users, so you have to build it in yourself to every app that you want to control.

[cy...]

Thanks again AQ

problem occurs when there are other earlier versions in circulation, where they are deployed during the time licensing is not built in it. And there is a need to enforce every system within the group to adhere and comply to the latest version, for standardization reasons. hence denying the runtime engine access for blacklisted programs can be a way to enforce version control on pre-licensing builds.

that said, following your recommendations, later versions should be build with licensing control within them. perhaps license leasing can work for standardization 

[AristosQueue (NI)]

If there was no licensing in first version, I know of no technology that would let you revoke the execution short of writing your own app that has deep hooks into the user's machine. That would be far outside LabVIEW's remit. You could write such a tool with LabVIEW, but your users would have to voluntarily run it.