Add a ReplaceDeprecatedNodes utility to help users update old applications.

[mjohanse-emr]

What does this Pull Request accomplish?

As part of this MDS release, we have deprecated/renamed a number of VIs and controls. The users application will still load, but it will have the typical red line through the deprecated nodes, etc. The utility introduced in this PR will recursively search a user selected directory for all .vi and .ctl files and replace the deprecated nodes with the new replacements. This is meant to handle:

• PolySubVI nodes with a selector (the selection will be preserved)
• PolySubVI nodes without a selector (like Get Value Type.vi)
  • These are treated like regular SubVI calls, so the replacement VI is no longer technically a PolySubVI. It's a SubVI call for the actual instance.
• Regular SubVI nodes (we didn't rename any of these, but we need this support to handle PolySubVI nodes without a selector).
• Controls on a front panel
• Constants on a block diagram
• Controls within a custom typedef .ctl file (both typedef and strict typedef)

Note: Right now, the deprecations are limited to Read Measurement and Read Condition workflows, so any changes by this tool should not affect what goes into the user's MDS database.

Note: This tool was created with the current set of deprecations in mind. I don't claim that it will handle all future deprecations without some additional changes.

It works as follows:

• Parse all the files in the user selected directory.
• Parse the deprecation info (old and new names) from an accompanying json file.
• For each .ctl or .vi file (.ctl's handled first to reduce VI panel conflicts):
  • Try to replace any PolyVI instances in the current file
  • Try to replace any SubVI instances in the current file
  • Try to replace any Constants on the diagram of the current file
  • Try to replace any Controls on the panel of the current file
  • If any replacements have been made, save the VI.

Why should this Pull Request be merged?

• Implements AB#3927049
• Allows clients to more quickly update applications to stop using deprecated nodes.

What testing has been done?

I saved off a number of VIs and Controls before the deprecation took place. I ran the utility on these files for testing. Testing was limited to making sure the VIs were not broken and that the replacements were performed correctly. I didn't execute the VIs before/after to compare results. I didn't think that was strictly necessary assuming visual inspection is sufficient. These files are attached to the azdo work item here (Pre Rename Code.zip or Pre Rename Code 2024.zip):
https://dev.azure.com/ni/DevCentral/_workitems/edit/3927049/

Concerns

Once concern is that I have been testing against the same set of files the whole time, which doesn't offer much breadth of testing. There's no way to predict what type of code the user will try and run this on, but perhaps as part of the review or validation a different set of "old" code is used to try and catch any bugs.

Another concern is that this ended up being a pretty complex set of LabVIEW VIs. While I've tried to think of all user cases, surely I've missed some, and there's certainly a chance there's a bug somewhere in this LV code. The consequences of any bad replacements will hopefully be obvious, but if they are close enough in type, they may just generate a coercion dot instead of a broken VI. This could potentially change the users application in an unwanted way.

Alternatives

If this utility seems too risky we could just not ship this utility and make clients do one of the following:

• Continue using deprecated nodes
• Manually replace the deprecated nodes
• Write their own script to replace the nodes.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[mjohanse-emr]

Replacing PolySubVIs in this manner doesn't work. It ends up cuasing broken VIs when converting read waveform (and other) nodes because the output value terminal doesn't line up with the old version.

[mjohanse-emr]

This work is being placed on hold due to additional problems found with the current implementation. At this point, it's not worth it to continue this development. I will leave the branch around in case we want to pick it up at some later point.