Jim Kring

That's strange. I wonder if there's some kind of permission issue. Does "Everyone" have Full Control on the "C:\ProgramData\JKI\VIPM" folder?

Hi Peter, Can you try exiting VIPM, deleting the cache folder, and then restarting? C:\ProgramData\JKI\VIPM\cache

Hmmm... which "list" are you referring to? The main VIPM package list or the Dragon project's Resources tree/list of packages? Also, can you look in the "C:\ProgramData\JKI\VIPM\error" folder to see if there's any error messages logged?

Hi @Yann. Thank you for sharing how IT resolved the issue for you. That's really helpful to know.

Hi @Sam Grayson and @Yann -- I'm also curious to learn more about how to configure Cybereason so that VIPM will work OK for you. Please let me know if your IT departments are willing to share more information.

Hi @Mario. Great question. As @James@Work point to, VI Package Configurations are a great solution for keeping track of the packages in your project. Additionally, JKI has announced the beta for Dragon, which sits above LabVIEW and VIPM to provide high-level management of LabVIEW projects and configurations of packages used by your project.

Fantastic! Glad to hear you're up and running.

I've seen that before -- sometimes VIPM's local package database doesn't get fully sync'ed Please try this: Open the VIPM Main window by clicking on the orange "VI" Then, refresh the package list in VIPM by clicking the refresh button on the toolbar You should then be able to find OpenG Toolkit by clicking on the link again or searching for it in the VIPM Main window.

That’s a great idea to show the build output, Joerg. I assume by “feed back the progress” you mean that you would like to see some progress text output to the standard output, which the CI is showing in the console?

Totally. I've opened a service request with NI to dig into it some more. I'll post updates, once I find out more.

I was able to reproduce the issue with the help of a colleague who has an RT Target. I've written up some info about this issue here: https://lavag.org/topic/21753-1d-array-to-string-not-compiling-correctly/ OpenG String v4.1.1.16 should fix this issue (although it's simply working around the LabVIEW compilation bug, which could potentially be causing other issues) I'm going to work to report this to NI, since we can reproduce the issue.

Ah, that's interesting. Maybe it's related.

Also, are you able to reproduce this issue right now? I might have a fix/test for you. If you've fixed it locally, maybe you can reproduce by uninstalling OpenG String from 2019 and then re-install OpenG. Being able to reproduce would really help me test a fix.

Oh, that's very interesting! Thanks. Question: is there any possibility that you opened this code on a Mac? (where the EOL character is a "\n" -- note that the EOL character is "\r\n" on Windows).

Hi Antoine, Thanks for posting this. Question: Do you have LabVIEW 2020 SP1 (2020.0.1) installed or LabVIEW 2020 (2020.0.0)? I'm trying to figure out how to reproduce this bug. -Jim

There are the ones that come to mind: C:\Program Files (x86)\JKI C:\ProgramData\JKI C:\Program Files (x86)\National Instruments C:\Program Files\National Instruments

@Mads Toppe, Thanks again. We've created an official knowledge-base entry for this issue: Knowledge Base: VI Package Manager Runtime Engine - Installation Media Required for Repair

Ah, that's good to hear that IT was able to figure it out. Glad it's working for you now.

Would you be able to check which versions of .NET you have installed? That's the only thing I can think of that would cause the code to open but be in a broken state.

Hi There. Sorry for the trouble. You said you tried installing VIPM that you download from JKI, here, right? vipm.io/desktop Yes, something seems broken. What do you see if you click on the broken run arrow?

Hi @Mads Toppe, Thats fantastic news. I’m really glad that worked for you. Thanks for sharing all the details about the problem and how you fixed it. We will create a knowledge base entry about all this to hopefully help anyone else who may get stuck in a similar situation.

Hi @Mads Toppe, Can you try this? Download this zipped up version of the VIPM Runtime Engine installer and point the "Select Distribution" dialog to where you extracted it? vipm-runtime-engine-19.1.3-windows.zip I'm hoping that will help you get past this step. The longer story is that it seems there's some deadlock happening due to the way NIPM and NI's older driver installers work. Hopefully, we'll get you going again. Please let me know if this works for you.

Hi @Mads Toppe, So that I can get NI support into the loop on this, can you please submit a bug report with NI and then respond back to me with the link to that ticket (you can send it to me off-line if you prefer). When you submit the ticket to NI, please list the steps you took to get into the situation (if you can) and also provide the screenshots you posted here in the forum. I can then work to get the ticket escalated and reproduced internally by NI so their dev team can figure out what happened. Thanks!

Hi James. Thanks for that extra information. Also, I am curious to lear more about how you're doing programmatic scan for package dependencies on a project. What I've seem most often is that the developer team is responsible for deciding which packages are dependencies of a project. Then, the automated build tool makes sure those dependencies are installed before the build. Can you tell me more about this? is this something you're doing on projects or just part of the proof-of concept? I'm working with our team to reproduce these issues and see if they can be fixed. Thanks.

Hi @Mads Toppe. What version of NI RIO is on your machine that you're trying to repair? A comment I got back from an NI support person is that the "dialog looks like a “metaInstaller” which would be pre-2019, in which case it’s an OS thing from the MSI installer. " I'm not sure if that's helpful or not. I'm hoping to hear more back from NI. I'll keep you posted.