kosist

Unfortunately, very useful and helpful ESF toolkit is still unpublished. So, I had it downloaded from NI forum, and installed globally. Now I try to install it locally, in lv-venv folder - but the following error occurs (trying to install it from Dragon window, by right-click on the toolkit in the list): When I open VIPM with the selected project (so not globally, but in venv context), result is the same - toolkit is shown in the list, but can not be installed. Then I switch to "global" configuration, select proper LabVIEW version -> toolkit could be installed there. Unfortunately now I don't have more unpublished toolkit to test the behavior - so hard to tell whether it is issue of the particular toolkit, or it is really due to the fact that this package is not published to VIPM repository.

Strange, but in some cases multiselect and Uninstall package does not work. I guess will be difficult to reproduce... But the point was that I had 10 globally installed toolkits. Selected all of them -> right-click -> Uninstall Package -> nothing has happened. Here is exact list of the toolkits: I've checked VIPM error log file, it had the following record: I've tried to select 9 toolkits, without OpenG Variant Configuration File Library toolkit. On Uninstall Package -> dialog window appeared, in order to confirm list of toolkits to be uninstalled. Cancelled it. Then I've uninstalled just Asynchronous TDMS Logger toolkit, and selected remaining 9 toolkits -> Uninstall Package -> toolkits were uninstalled. Not sure whether it is reproducible for the same toolkit's list on another machine - maybe it is issue at my side just.

It would be nice to be able to filter global Resources list, at least in order to display just those toolkits which are used by the project. During migration to virtual environment - according to the explanation video - after we've created VIPC of used toolkits (as a backup), we could safely remove globally installed toolkits, and then install them locally. But when there is a lot of globally installed toolkits, then it could be easier to filter them -> display just those which are used by the project -> and then delete them. Just a cosmetic point, because anyway such toolkits could be detected by the icon now.

When double-clicked on the toolkit in the Resources tab, and that toolkit is installed globally and locally at the same time - then the following window is opened: So somehow it does not show toolkit's information, and does not detect versions of LabVIEW installed. On right-click -> Open Package Info for the same toolkit everything is fine, toolkit's information is displayed. When I do double-click on the toolkit which is installed just either locally or globally, then everything is fine - toolkit's information is displayed.

When there are missing required packages and project is opened, Dragon asks to install missing required packages. But, it would be great to display in this dialog window what exact packages are missing - just to know in advance whether it is really needed to install them now.

It is possible to edit LabVIEW version manually - but not sure, whether it should be like that. If it is auto-detected, then it could be just an indicator. But anyway it does not influence on the behavior (and that's fine) - for example, when I set LabVIEW version to 2017 it does not try to open project in LV 2017.

I was creating Dragon configuration files manually for multiple projects, and by copy-paste it came to the state that VIPC file path was not valid anymore. But then, there were not listed neither packages installed globally, nor packages installed to lv-venv folder. Resources page view But it seems, that missing VIPC file should not influence at least global packages list...

Great! First I thought that it works just for projects which are located at the same level in the folder, but it comes that project itself could be inside of subfolder, and Dragon cfg file - in some another (top-level) folder.

Not sure that it will be possible to replicate the issue, but let me please describe how did it happen. For our package we have setting "Bind menu palette to library". And at the end of the build, VIPM starts to search "*.mnu" file (not sure that this is also normal behavior). Then it can't find it, opens dialog window to select it - but as it does not exist yet, we usually just close that window, and build is finished. Yesterday I've started the build on PC, and came back to it just today. So build was "active" around 21 hours (not sure that this is important, but point is that dialog window was opened quite a long time, maybe it has some influence on the error). And today there was still opened window to select "*.mnu" file - I've cancelled it as usually, "Compress package" operation continued for a while - but then error occured: I've closed error message window, and decided to start build again. Pressed "Build Package" button, but received error that target LabVIEW version can not be found (or something like that). So seems that above internal error also "broke" something else, so I had to restart VIPM. After restart of VIPM, build was finished successfully (although still there was dialog window to select menu file, but it was not a problem).

Release notes are written in the build specification. When, for example, developer realizes that some note should be added - package has to be rebuilt. But sometimes build of the package could take a lot of time (for example, build of our DBT toolkit takes approx. 1 hour with licensing, password protecting and further build). It would be great if there will be option to update just release notes, or another information which should not be compiled (authors list, etc.). That would help to save some time... But on the other side, developer should pay some more attention to build configuration before actually building the toolkit...

I've seen similar behavior during building of LabVIEW application installer. We've installed LabVIEW 2019 some time ago, and then cleared NI Packages cache. Then later on we had to build executable and installer. Executable was built without issues, but with installers were problems - LabVIEW "asked" to provide installation media for various distributions/drivers, including VIPM Run-Time Engine (which had nothing to do with our application). Reinstalling VIPM didn't help. In our case, the solution was to repair LabVIEW completely, using installation media.

Somehow post was posted twice, so I've edited second copy with this message, please ignore it...

Great idea! Especially useful for packages for which it takes long time to install - because usually error caused by non-admin rights is dropped at the very end of the installation. But if it could warn user before the install - then some time could be saved. And also, sometimes it could happen the situation that: - LabVIEW is not running; - VIPM is launched; - toolkit is installing -> VIPM launches LabVIEW; - installation fails because of non-admin rights; - user closes VIPM, but LabVIEW remains to be running; - user launches VIPM as admin; - toolkit is installing -> but fails because LabVIEW is already running as non-admin; - so user needs to know that he has to restart not just VIPM as admin, but also close LabVIEW so VIPM could launch LabVIEW again with admin rights.

This is very small issue, but anyway let me post it here. It would be nice to set scrollbar in the list to the start position, when the view is shown. Because now it happens that, for example: user opens "New Releases" view; scrolls down; presses "Go back"; presses "Most Installed" button; Most Installed view is opened, but the scrollbar is set to previous position as it was at "New Releases" view. And it could be a bit confusing, because if user does not notice scrollbar position, he could think that those items in the list are the top one, but indeed they are not.

I've navigated using VIPM Browser as the following: Launched VIPM Browser. Pressed button "New Releases" (but it is valid for other buttons "Most Starred", "Most Installed" also). Clicked on the package in the list. Pressed "Go back" - and it returned me to start screen. It would be nice that it would return user to previous screen (like in my case - to "New Releases" screen).

I've tried to press "New Release" button in VIPM Browser, and noticed the following. After it has retried information (it took some time, but I guess that's OK) - first time I've seen the same list as at vipm.io. Then I've pressed button "back" in the left upper corner, and then again button "New Release". And then it showed something completely else: So there was toolkit which is installed internally, and is not published. Also, there are items without names in the list: When I click on that row, it shows details window which is empty. Could it be those so-called "System" toolkits which are sometimes installed along with the toolkits? As the reference, let me attach screenshot of the current "New Release" packages at vipm.io It seems that for some reason, it started to display locally installed toolkits, or something like that. Restart of VIPM and VIPM Browser didn't help... I've tried also "Most Starred" button. The first page seems to be fine, but when I've scrolled down - there was the following item. ANV Quick Drops - we didn't publish this toolkit, so it can not have stars (because this feature is available on web just). "Most Installed" button - first times it showed proper views, but then it started to show this toolkit as the most installed: But when I click on it, it shows another information about number of installations: Seems that there are some bugs with these views... Thank you very much, Sincerely, Ivan.

Hello @Jim Kring, thank you for the provided files for unpack/repack the package. I've tried to implement post-build action, but seems that there are 2 issues. 1. Seems, that post-build action is not executed. I've put breakpoint to post-build action VI - and nothing happened during the build, VI was not executed. Also, spec file was not modified. Could it be the bug, and post-build action is disabled for Community edition (the same situation as with flags?). 2. I've prepared VI in order to modify package manually (as post-build action was not called). When I run it, spec file is modified. But, when I try to install toolkit via VIPM, the following message occurs: Seems, that VIPM "doesn't like" package after re-pack operation... Does it check some checksum of the file or something? Thanks a lot for your help, Sincerely, Ivan.

Hi @Jim Kring, thank you for update; I'm going to try that post-build action. This build was done using Community Edition (and I'm working on open-source toolkit). Did you check please that this option is really set in spec file? But maybe if you use another build, that issue does not exist there already (I have VIPM 2020.3, build 2540). Thanks a lot for your help!

Hello @Jim Kring, sorry for the confusion, have no idea why I've written like that... What I meant - is that LabVIEW is not restarted after toolkit is installed. I'll update original post, sorry for that. I've checked spec file as you've suggested, and really there is set "FALSE" flag for LV restarting. Let me show the screenshot of toolkit's configuration, and resulting flags in spec file. Let me also attach dummy package which reproduces the issue. Thank you very much for your help! Restart Issue Toolkit.zip

I've tried to build package using VIPM 2020.3, and set option "Restart LabVIEW After Install". Package is built without issues, but when I install it - LabVIEW is not restarted. Previously I was using such option with VIPM 2019, and everything worked fine... Am I missing something please, or this feature really does not work now? Thanks a lot in advance!

Let me share the following idea. It could be nice to extend VIPM login feature in a way that it would allow to store list of installed packages based on machines, and LabVIEW versions. When user is logged in - he could create such configurations, and synchronize them across machines. Configuration could be stored online, along with credentials used for VIPM login. It could allow then to login into VIPM, see and install missing packages on the particular machine. I know that it is possible to create vipc files, but anyway this does not guarantee that package configuration file will be up-to-date. And, it requires manual work - create vipc, copy somewhere, then transfer to new machine. Such feature could be useful while installing packages on new machine (customer's machine for the project needs, virtual machine for testing purposes or when developer simply changes his development PC).

Thank you @Jim Kring, now it is clear.

If user has claimed toolkits on vipm.io, there is visible button "Release New Version" at the toolkit's home page. What does it actually do? Does it allow to immediately publish the updated version of the toolkit, or it sends it for the review to NI? Because now in order to do update of the toolkit we could also send it via special form to NI, they do some brief review, and then publish updates. Does "Release New Version" do the same thing? Or, it depends on the type of repository where the toolkit is hosted - like, if it is hosted at LabVIEW Tools Network repository then we need to send it to NI, if it is some open source toolkit then we could publish it directly? Thanks a lot in advance!

Hello @Jim Kring, thank you, actually yes, it is already displayed as "Unpublished" in the "Repository" list. Just, this status is displayed also for toolkits which have never been published - for example, toolkit's development is in progress, and it is just installed locally in order to check how it works. The same happens when it is installed via VIPM which does not have license to publish packages. Or, when there are installed toolkits (like ESF, Dictionary, etc.) downloaded from somewhere, and which have not been published also. But nevermind, and thank you for the idea - it is possible just to sort list by Repository, so Unpublished toolkits will be on top, and thus immediately visible that something is not updated. That is enough in order not to forget to publish the package. P.S. Interesting to see Dragon icon already directly in VIPM

Currently at our company we are building internal toolkits which we use for projects, but do not put it to LVTN. Toolkits are published via OneDrive, everyone has mapped same local folder as repository in VI Package Manager. Different toolkits are handled by different developers. And sometimes there is a situation, when new version of toolkit is built, installed locally and tested, but it is not published to our local repository. It would be nice (I understand that on the other hand it is not such a common case) to have it in such a way, that: - developer installs new version of the toolkit; - VIPM detects that actually such a toolkit (based on name and version) has been previously installed from a locally configured (custom) repository; - if so, VIPM checks that this toolkit has not yet been published to that local repository; - it will display some icon similar to those which are in "VIPM Legend" list. In that case, developer would see that he has some toolkit which is not published - so either he will publish it, or leave it as it is. Also there could be warning similar to the one which is shown when VIPM is opened, and there are updates for the toolkit. And, when toolkit is published - icon is set as usually.