C# DLL shared Memory .net App & LabVIEW

[gortosch]

Grüße,
meines Wissens müsste es doch in C# ausreichen z.B. ein Attribut als static zu deklarieren damit zwei Anwendungen, die diese DLL nutzen hierüber Daten austauschen zu können. Rein in Lab VIEW mit einer eingebundenen .net DLL funktioniert das auch wunderbar ebenso in zwei .net Applikationen nur in der Konstellation Lab VIEW .net App nicht.

Kann mir vielleicht jemand bei diesem Problem helfen? Danke.

Gruß
Sven

[Konrad Rudolph]

Dein Verständnis ist leider falsch. Die DLL wird in dem von Dir beschriebenen Szenario mehrmals geladen und bekommt so jedes Mal einen eigenen Adressraum zugewiesen. 'static' bezieht sich lediglich auf diesen Adressraum.

[gortosch]

Wie ich gerade sehe läd Lab VIEW die DLL neu d.h. die .NET dll liegt 2x im Speicher. Warum dass denn? Kann mir hierzu vielleicht jemand nen Tipp geben? Ich bin am verzweifeln, scheiß Lab VIEW.

Die .net App läd genau die DLL aus genau dem Verzeichniss das ich auch angebe.
Lab VIEW hingegen läd eine dll aus C:\Dokumente und Einstellungen\benutzer\Lokale Einstellungen\Anwendungsdaten\assembly\dl3... !

Gruß
Sven

[gortosch]

Konrad Rudolph schrieb:

Dein Verständnis ist leider falsch. Die DLL wird in dem von Dir beschriebenen Szenario mehrmals geladen und bekommt so jedes Mal einen eigenen Adressraum zugewiesen. 'static' bezieht sich lediglich auf diesen Adressraum.

Okay, was wäre denn dann zielführend?

Danke.
Gruß
Sven

[Konrad Rudolph]

Na ja, für diesen Zweck gibt's IPC. Direkter geht es nicht. Setz Dich z.B. mal mit Named Pipes auseinander, z.B. http://www.codeproject.com/KB/threads/dotnetnamedpipespart1.aspx

[gortosch]

Vielen Dank. Aber mit C Dll's gings doch auch, warum sollte es mit C#(.net) Dll's jetzt nicht mehr gehen? Das wäre ja ein Rückschritt.

Gruß
Sven

[Konrad Rudolph]

gortosch schrieb:

Vielen Dank. Aber mit C Dll's gings doch auch

Nein, das ging auch mit C-DLLs nicht, zumindest nicht auf NT-Systemen mit echten Prozessgrenzen.

[Unix-Tom]

Das geht in C++ auf einem Windowssystem nur wenn man auch eine Sharedmembereich hat und die DLL aus dem gleichen Ordner kommt.
In Windows wird eine DLL nicht wirklich 2 Mal geladen.
Sollte sie sich bereits im Speicher befinden und kommt der 2te aufruf der DLL aus dem gleichen Ordner und der gleichen Datei dann wird sie nicht neu geladen. Deshalb kann man dann auf den Sharedmem-Bereich zugreifen.
Ob es mit NET-DLL genauso ist weiß ich aber nicht den ich habe es noch nie gebraucht.

[gortosch]

Konrad Rudolph schrieb:

gortosch schrieb:

Vielen Dank. Aber mit C Dll's gings doch auch

Nein, das ging auch mit C-DLLs nicht, zumindest nicht auf NT-Systemen mit echten Prozessgrenzen.

Natürlich...

[simon.gysi]

natürlich was?

[gortosch]

simon.gysi schrieb:

natürlich was?

Natürlich geht das. Haben wir schon erfolgreich eingesetzt. Nur, jetzt geht es um Callbackevents und die sind leider nicht in einer C DLL realisierbar.

Gruß
Sven

[simon.gysi]

Den Trick musst Du mir zeigen..

[Unix-Tom]

Auch wenn eine DLL nur einmal geladen wird hat jedes Programm mit zugriff auf die DLL seine eigene Prozessgrenze.

Du kannst also keine Wert in einer DLL speichern und von einem anderen Programm aufrufen wenn du nicht eine Sharedmem. einrichtest.

[Konrad Rudolph]

Abgesehen davon sind übrigens auch Callbacks in C-DLLs realisierbar. Was glaubst Du, was 'WNDPROC' ist?

[gortosch]

Konrad Rudolph schrieb:

Abgesehen davon sind übrigens auch Callbacks in C-DLLs realisierbar. Was glaubst Du, was 'WNDPROC' ist?

Nicht mit Lab VIEW.

Auch wenn eine DLL nur einmal geladen wird hat jedes Programm mit zugriff auf die DLL seine eigene Prozessgrenze.

Du kannst also keine Wert in einer DLL speichern und von einem anderen Programm aufrufen wenn du nicht eine Sharedmem. einrichtest.

Ist schon klar, darum ging es aber nicht. Wie man eine DLL mit Shared-Memory schreibt ist mir durchaus klar.

@ALL lassen wir das ganze. Haben jetzt einen anderen Lösungsansatz gewählt.

Gruß
Sven