LabView DLL in C# nutzen

Hallo zusammen,

ich weiss nicht ob ich im richtigen Bereich bin.
Kann ja sein, dass ich mich in der Richtung DLL-> LabView befinde - dann bitte verschieben.

Ich habe ein VI, welches SubVi's nutzt.
Dieses wurde durch den Application Builder als "Shared DLL" (nicht Interop) kompiliert.

Bei Quelldateien -> Prototyp festlegen habe ich:

<Void>
<Name>returnvalue</Name>
</Void> IPSupplyGETCurrent(Bool Start, out Bool End, Cluster FehlerEingang, out Cluster FehlerAusgang)

Somit erscheint mir im Header-File im Build Ordner als

Code:

#include "extcode.h"
#pragma pack(push)
#pragma pack(1)

#ifdef __cplusplus
extern "C" {
#endif
typedef struct {
    LVBoolean status;
    int32_t code;
    LStrHandle source;
    } TD1;


void __stdcall IP_Supply_GET_Current(TD1 *FehlerEingang, LVBoolean *Start,
    TD1 *FehlerAusgang, LVBoolean *End);

long __cdecl LVDLLStatus(char *errStr, int errStrLen, void *module);

#ifdef __cplusplus
} // extern "C"
#endif

#pragma pack(pop)

Wie kann ich die nun in C# importieren?

Stand bisher:

class IP_Supply_GET_Current
{

[DllImport("C:\\Users\\test\\SharedLib.lib",
EntryPoint = "Test",
CharSet = CharSet.Auto,
CallingConvention = CallingConvention.Cdecl)]

public static extern unsafe IP_Supply_GET_Current( noch unbekannt... )


Würde mich freuen wenn hier eine interessante Diskussion dazu entstehen könnte.
Im Developer-Bereich bei NI werde ich nicht wirklich fündig, jedoch ist das Thema keine Randerscheinung.

Gruß

---

Da nicht weiß wie man editiert hier eine Verbesserung des oberen Posts:

Natürlich schauts bei der Shared-DLL im Application-Builder (2010) so aus:

void IP_Supply_GET_Current(TD1 *FehlerEingang, LVBoolean *Start, TD1 *FehlerAusgang, LVBoolean *End)

Einstellung: C-Aufrufkonvention

Wieso kompilierst du sie als Shared Library und nicht als .NET Interop Assembly?

Ich habe zwar beides noch nicht gemacht, aber in der .NET Umgebung ist es doch einfacher einen .NET Assembly zu laden als Nativen Code (oder Unmanaged Code)?
Wo liegt der Vorteil?

Gruss,
\c

Ja, mache eine .Net Assembly. Das spart Dir eine Menge managed<->unmanaged Misery in Deiner .Net Applikation. Und wenn Du dann unbedingt eine normale DLL verwenden willst, vergiss ganz schnell Cluster als Parameter zu verwenden. Das zu managen (wörtlich gemeint im Sinne der managed Umgebung von .Net) muss von Dir händisch gemacht werden und ist einfach sinnlose Mühe.

Was die C# Syntax des Prototypen betrifft kann ich Dir auch nicht helfen. Bevor ich C# auch noch lehre geht wahrscheinlich die Welt unter. Erstens ist es Microsoft, zweitens ist es bei Microsoft Technologien üblich dass sie nach ein paar Jahren durch den nächsten neusten Schrei ersetzt werden, und drittens sind Pascal, Modula, LabVIEW, C, Lua, Java und etwas C++, Python und Assembler meiner Meinung einfach genug.

(19.08.2011 07:00 )rolfk schrieb:  ... und drittens sind Pascal, Modula, LabVIEW, C, Lua, Java und etwas C++, Python und Assembler meiner Meinung einfach genug.

das klingt jetzt aber ein wenig sehr konservativ, findest du nicht?

---

Aber bevor ich es mit einem Cluster versuchen würde, wenn es wirklich eine DLL sein soll, würde ich lieber alle Werte einzeln übergeben ... da hast du, zumindestens in C, mehr Chancen mit. Und dann solltest du dir die Frage stellen ob du die dll in C dynamisch (also während der Laufzeit) oder statisch (immer) einbinden willst. Hier ist Google dein Freund und am besten schaust du gleich nach einem Beispiel für deine Programmierumgebung (Visual 2005 solltest du gar nicht erst versuchen, falls du dynamisch einladen willst, da fehlen die win32api-funkionten, glaub mir ich hab eine Woche nach gesucht).