Jim Kring

Thanks for the great post with detailed steps to reproduce! I have a few thoughts about the situation you described: Dragon Should Probably Not Allow Installing Packages into Both Global and Virtual Environments First, I generally think Dragon should move in the direction of not allowing a package to be installed globally AND in the virtual environment, due to the conflicts and cross-linking that can happen. Right now, Dragon is allowing that in order to have flexibility until we work out all the details and more fully understand the various use cases. Caraya Should Probably Build JKI SM Into Itself (not expose it as a dependency to users) Second, I would like for Caraya to not depend on the JKI State Machine (so, perhaps it should build in the JKI State Machine as an internal dependency and not expose it to users) -- it's such a core utility, it's not actually a library that gets built into the end-user's distributable application, and it's probably better not to expose users to a dependency constraint. All that is to say: "Maybe eventually Caraya shouldn't require installing the JKI State Machine, so part of this problem might go away" Libraries and IDE Extensions Should Probably Be Split onto Separate Packages As you pointed out in this other topic, the JKI State Machine may eventually be split into two packages: One that contains the library code that the user will call directly in their applications (which will naturally be best installed into the lv-venv) and another that contains the LabVIEW IDE extensions: right-click menus, etc. (which will need to be installed globally). This eventuality we're considering doesn't directly follow from the example you posted about Caraya, yet I figured it was worth mentioning and we're giving it a bit of thought right now. This would possibly require package developers to be more aware of virtual environments and the need to split a package into two parts -- and, it would be nice if VIPM's package builder and/or VIPM/Dragon could help do this automatically. Again, we're thinking about the best ways to do this. Try Installing Caraya into the Virtual Environment It might be a good idea to install Caraya into your virtual environment. I think there may be a few quirks that don't work great like the Tools menu options, but for the most part, I think Caraya works well when installed into the lv-venv.

Good catch. We'll have this fixed in the next build (>=2715)

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

Hi @kosist Thanks for that information. Can you tell me more about the exact steps you might have used when the error showed up? First you said "Install ESF toolkit globally" then "Try to install ESF toolkit from Dragon window, by right-click on the toolkit in the list". What did you right-click on to try install it into the virtual environment? Did you add it to a VI Package Configuration, uninstall globally, then try to install it locally? Any specific steps would be very helpful. Thanks!

yes, that's right -- the .dragon file can be placed in the very top level folder of the project source code and the .lvproj, .vipc, and .vipb files can be kept in subdirectories. There's a new feature in the latest build that helps with this, too. When you're opening a new project for the first time, Dragon will search in subfolders (up to two levels deep) for these .lvproj, .vipc, and .vipb files when it auto-populates the dragon project configuration for the first time.

Good catch! I agree that a missing .vipc file should not cause Resources package lists to be empty. We'll fix that...

That's a really good point -- a user probably doesn't feel 100% comfortable agreeing to installing all the packages until they know what packages will be installed.

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 @kosist. Thanks for sharing your observations about this. Here's what's going on. Currently, there is not much validation of the LabVIEW Version requirement. Eventually, there will be more validation and user feedback. A.) For projects that use a virtual environment, the LabVIEW version in the virtual environment is used for determining which LabVIEW version to use for editing the project. B.) For projects without a virtual environment, the LabVIEW Version of the dragon project configuration is used for determining which LabVIEW version to use for editing the project. C.) Also, when creating a new virtual environment, the LabVIEW Version of the dragon project configuration is used for determining which LabVIEW version to use for creating the virtual environment (goto "A"). As such, if a project has a virtual environment, then the LabVIEW Version in the configuration is somewhat ignored, currently. In the future, we'll add more enforcement and checking of this, when it is changed by the user or if it ever differs from the virtual environment.

There's a new build of dragon that fixes this issue with the Please Wait dialog text cut off. Download it here.

There's a new build of dragon that fixes this issue and allows packages with Friend Classes to build correctly. Download it here.

There's a new build of dragon with Multi-Select in the tree. Download it here.

There's a new build of dragon that now correctly shows palettes for Instrument Drivers, User Libraries, and Add-ons correctly. Download it here.

There's a new build of Dragon and VIPM 2021 Beta: Download it here Here's what's new: Improved Palettes for Virtual Environments - Virtual Environment Palette now show Instrument Drivers, User Libraries, and Add-ons correctly (reported here) Multi-select - Select and operate on multiple items/packages in the Resources tree-view to allow install/uninstall multiple packages at once (reported here) Improved New Project Configuration Detection - new project dialog will now search in subfolders (2 levels deep) for the .lvproj, .vipc, and .vipb file -- this is helpful if the root folder of the project does not contain these project files, and they are located in subfolder. Missing Friend Classes No Longer Cause Package Build Errors - The package builder was raising a dependency missing error if a friend class could not be found. However, friends are not actually required. Now they don't cause a missing dependencies error (reported here) Improved "Please Wait" Dialog - Fixed text cut off in the Please Wait Dialog (reported here) Here are more details for a few of the new improvements: Improved Palettes for Virtual Environments Virtual Environment Palette now show Instrument Drivers, User Libraries, and Add-ons correctly. Multi-Select You can Ctrl+Click or Shift-Click to select multiple items in the tree. Right-click actions apply to all selected items, as you can see in the animated screetshot below. Improved New Project Configuration Detection The new project dialog will now search in subfolders (2 levels deep) for the .lvproj, .vipc, and .vipb file -- this is helpful if the root folder of the project does not contain these project files, and they are located in subfolder.

Hi Steven, LabVIEW plug-ins launched via quickdrop, right-click, project providers, tools menu, etc, typically get run in a different application instance and thus have their own VI namespace — each application instance can have VIs in memory with the same name, but loaded from different locations on disk. I hope that helps.

Great idea, @Steven Dusing! We're working on this and it should be available in the next build.

This is really great feedback @Ryan Good. First, I agree that the Package Properties window gets in the way when trying to use it to manage dependencies, due to its modal nature. Also, I agree with you that there are use cases for installing some packages globally -- in fact, some packages really need to be installed globally to fully work (right-click extensions, project providers, etc). And, it would be nice to be able to manage/visual dependencies easier. Here's a summary of what I think the use cases are: - It would be nice to be able to specify if a package should be installed globally or into the lv-venv. - It would be nice to more easily add package dependencies (and sub-dependencies) to a project configuration - It would be nice to more easily see/know a package's dependency information -- know whether a dependency is a direct/primary dependency or a dependency of a dependency (indirect/secondary/tertiary). Does that cover the use cases for this? Can you think of others or a need to further clarify any of the above?

Thanks for reporting this @Joerg Hampel. Yes, there is currently a problem with this feature -- we're working on it.

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

Yes, that could be the issue. This issue often appears when you get to the package properties dialog by double-clicking a package in Windows Explorer and it's not yet in the package cache.

Thanks for reporting this @Benjamin Rouffet -- it should be fixed in the next beta build.

Hi @Joerg Hampel. Ouch! That's not good. I'd be happy to try a screenshare to see if I can assist or learn more about what's going on -- please let me know. Can you see if the main VIPM process can run? Try launching "C:\Program Files (x86)\JKI\VI Package Manager\VI Package Manager.exe" You can look in the error logs folder here for error information: "C:\ProgramData\JKI\VIPM\error" Also, with LV2019 (note VIPM 2020+ uses the LV2019 Runtime Engine) NI announced LV2019 it will not work in Windows 7 without service packs, however, I see that you're running Win7 SP1, so that might not be the problem. It could perhaps be an issue with VIPM needing a newer version of .NET installed.

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.