Can LabVIEW Memory manager be run Headless for testing - Owned Types

[jkneer]

The API is loaded using load_self(), which assumes that LabVIEW loads labview-interop when executing DLL calls from VIs.

With the advent of Owned Types this may not necessarily be True, i.e. for tests that need the LV memory manager, but do not require to be launched through LabVIEW.

Proposed solution:

• Can we detect if we run the link feature standalone and if we do have a DLL path detection?

Now after having written this, I wonder if LV does actually support a headless operation of the memory manager, maybe with the LV Runtime?

[JamesWiresmith]

I can dig deeper, but I'm pretty sure this isn't possible since we are linking to functions in the LabVIEW exe, which become available when loaded in that context. I don't believe there is a way to link to these through a separate library.

[jkneer]

It would be nice to have this as it would make writing tests for all the functionality interfacing the memory manager much easier.

[JamesWiresmith]

Yep it would be easier. Right now though the way to test this is through the VI tester library in LabVIEW. There is a script in the justfile for this (https://github.com/WiresmithTech/Rust-LabVIEW-Interop/blob/main/justfile) which can give a sense of what is required. I need to tweak it to use a public VI tester runner.

You can try running through https://www.vipm.io/package/sas_workshops_lib_vitester_for_g_cli/ instead - should just need the capitalization in the command changing.

Alternatively you can run it through the VI tester UI as shown at https://github.com/vipm-io/vi-tester/wiki/UI-Overview

[JamesWiresmith]

I had another thought around this, I'm not sure if this can work but maybe we can load the runtime into memory instead (LVRT.dll). The question is how easy is it to initialize and does it need to be initialized for the basic functions