WATS TestStand Plugin versus .tsenvAnswered
We use the capability of TestStand to work with an exported TestStand environment (.tsenv).
The WATS TestStand plugin is installed in the default TestStand directory.
The only way we have is to detect manually and copy each component of the TS plugin and paste them into our exported TS environment.
That works well, but it would be great to have the possibility in a next released to choose where to install the WATS TestStand plugin.
We have now discussed this and we do not plan to add support for TestStand (TS) environments by default from the add-on installer. The advantage today is that the Client do not need to activate TS to install the add on files if you have multiple TS versions installed. Also, it seems that you can have multiple and distributed .tsenv files in the TS environment, which make it even more complex for the WATS installer during client upgrade (would have to install the add-on files on multiple locations, including the "none active" environments).
One suggestion would be that you run a custom script (maybe as a Station callback?) copying the files from C:\Program Files\Virinco\WATS\SupportFiles into your active environment folder(s).Comment actions
You could add a feature in the WATS client to "install in using tsenv". There could be another button and when you click on it it will ask for the tsenv file. WATS client could then install TS add-on in the public folder specified in tsenv and kind of register it in some WATS file. This file could be used by the client to uninstall tsenv/public/addon. In addition to this, the WATS client could install uninstall "tool" in the public folder specified in tsenv (this might be helpful if you move "registered" tsenv and the WATS client lose it - the aforementioned register no longer points to the appropriate location). It might also install "upgrade/update" WATS tool. Also, CLI for this would be appreciated.
Please sign in to leave a comment.