Is it possible to access the native buffer from LabVIEW when a DLL is written in C++/CLI (.NET)

[chigaitakanoha]

Hi,

I have a DLL written in C++/CLI and have a property available to LabVIEW to access the native memory space, but from the property I can't use examples described in this link: https://forums.ni.com/t5/Developer-Center-Resources/Calling-C-C-DLLs-Containing-Simple-and-Complex-Datatypes-from/ta-p/3522649

Is it because the DLL must be written in pure C/C++ instead of C++/CLI (.NET) ? 

Thanks!

 

[smithd]

The page you linked to is only for c dlls. If its a .net assembly dll, you can use the labview .net interface.

https://forums.ni.com/t5/Developer-Center-Resources/Calling-NET-Assemblies-from-LabVIEW/ta-p/3523180

to test this, drop down a constructor node and from the dialog, select browse and locate your dll. If it loads, you're in the right spot.

[chigaitakanoha]

Thank you Smithd, I am able to access the managed memory space. I am trying to access the native memory space. So what has been done is this I have a buffer in the native and that's marshalled and stored in the managed space for LabVIEW to access. I am trying to access the native buffer from LabVIEW. 

Thanks,

[chigaitakanoha]

Has anyone here ever used BlockCopy function for a library written in .NET (C++/Cli) ? 

https://forums.ni.com/t5/Developer-Center-Resources/Dereferencing-Pointers-from-C-C-DLLs-in-LabVIEW/ta-p/3522795

[Rolf Kalbermatter]

Why do you post this in the LAVA Lounge and not in the LabVIEW->External Code forum?

You really need to give more information. You mention .Net, C++ and CLI. That is all possible to combine, though not necessarily the most common way. You talk about native pointers and managed memory in a somewhat ambigous way that makes it very hard to know what you really have.

A memory pointer is not simply a memory pointer. It is important to know how it was allocated and with which exact function. That determines if a simple pointer is still valid when accessed from a different managed environment or not. Generally memory allocated in one of the involved managed environments (.Net or LabVIEW) can only be accessed through functions of that managed environment, otherwise you need to do marshalling, which LabVIEW does automatically when you use the .Net functionality in LabVIEW.

If your C++ code explicitly allocates memory through Win32 API calls or Standard C runtime calls (C++ allocations could be trickier especially in combination with compilation as .Net assembly), this memory is not managed by .Net but by your code. If you pass this pointer to LabVIEW and make sure that the pointer remains valid (no realloc() or free() calls at all ever between passing the pointer to LabVIEW and trying to access it in LabVIEW) you can simply use the function MoveBlock() as mentioned in those linked articles.  Of course you need to understand the difference between a pointer and a pointer reference in order to be able to correctly pass this pointer to the MoveBlock() function.

Show us your code and what you think is not working there.

One other question is why do you use C++ when you want to create a .Net assembly (or the opposite, why create a .Net assembly when you want to use C++). It is not the most logical combination as your .Net assembly still contains non IL compiled code, so is equally binary platform specifc as a normal DLL. Creating a real DLL instead might be more straightforward.

Edited January 19, 2019 by Rolf Kalbermatter