eigene .dll in Python

[reinerdoll]

@ deets : ja, aber nichts gefunden.
die externe library für den opc-zugriff finde ich in der registry,
aber die .exe für den rfid-controller ist mit der suchfunktion in der registry nicht aufzuspüren.

imho ist das opc-dings also vermutlich eine com-komponente, die rfid-treiberdatei aber nicht.


@sirius : das mit der fleißarbeit ist so ne sache, der c#-quellcode hat über 2500 zeilen.

du schreibst, als .net-dll sollte sie nutzbar sein. mit syntaxvarianten aus dem web hab ich das bisher nicht hingekriegt.

[BlackJack]

@reinerdoll: Wenn das aus dem C#-Compiler rauskommt, dann ist es keine native EXE, sondern eine .NET-EXE. Wenn man den Code darin auch von anderen .NET-Programmen aus nutzen kann, dann wird so eine .NET-EXE wohl auch wie eine .NET-DLL nutzbar sein. Ist ja letztlich auch das selbe drin: .NET-Bytecode, nur das bei der EXE noch ein nativer ”Stub” davor steht der die .NET-Laufzeitumgebung startet um den Bytecode in der EXE auszuführen, damit man die EXE so starten kann als wäre es eine normale/traditionelle EXE.

Wenn es die Möglichkeit gibt, dass Du irgendetwas hast/brauchst was es nur für .NET gibt, jetzt oder in der Zukunft, dann müsstest Du jetzt erst einmal abklären ob und wie man das von CPython aus benutzen kann, ansonsten bist Du dadurch auf IronPython festgelegt. Es gibt für CPython so etwas wie JPython für .NET: Python for .NET.

Noch mal zur Motivation: VB ist auf einem absteigenden Ast? Dann nimm doch C#. Ich glaube ich hatte es schon mal geschrieben: VB ist seit VB.NET doch eh nur eine andere Syntax für C# damit man die ganzen alten VB6-Programmierer zu .NET rüberholen konnte. Ich denke nicht das Microsoft VB.NET in absehbarer Zeit einstampfen wird, also ist das auch nach wie vor noch eine ”sichere” Sache.

[reinerdoll]

Ich hoffe ich nerve nicht. ich hab jetzt hier schon ne menge über com und .net und so gelernt, deshalb noch eine frage :

ich habe folgende .net standard-dll (in vb geschrieben) :

Code: Alles auswählen

Public Class Class1
    Public a As Integer
    Public Sub doppel()
        a = a * 2
    End Sub
End Class

die ich so versuche in python zu nutzen (kein com-objekt erzeugt !) :

Code: Alles auswählen

from ctypes import *
objekt = cdll.LoadLibrary("C:\\experimente\\doppeltest1\\doppeltest1\\bin\\Debug\\netstandard1.4\\doppeltest1.dll")
objekt.a = 2
objekt.doppel()
print(objekt.a)

(ich weiß, fast das gleiche hatte ich schon mal)
jetzt aber die frage nach einem detail : wenn ich den methodenaufruf objekt.doppel() rausnehme, klappt das, ich kann mit dem attribut doppel.a arbeiten. der methodenaufruf aber klappt nicht. wieso das attribut, aber nicht die methode ??

[Sirius3]

@reinerdoll: mit ctypes kann man keine Klassen importieren. Man kann nur einfache Funktionen aufrufen. Dass das mit .net-DLLs überhaupt geht, hatte ich bisher nicht gewußt, aber hier wurde ich fündig. Dass Du dem Objekt `objekt` Attribute hinzufügen kannst, liegt daran, dass Python dynamisch ist, hat aber nichts mit dem Attribut `a` Deiner VB-Klasse zu tun.

[reinerdoll]

kann ich in vb ne function "doppel" schreiben, die ich dann mit ctypes.CDLL aufrufen kann ?

[__deets__]

Das wuerde mich wundern. Eben weil das C-FFI (foreign function interface, also Aufrufkonvention wie man C-Funktionen anspricht) NICHT ausreichend ist fuer objektorienterte Programmierung, hat MS COM erfunden. Das VB da ploetzlich von Abweicht waere ueberraschend. Wenn es das taete, ginge es auch nur fuer sehr eingeschraenkte Faelle.

Du kannst unter Windows das Programm DUMPBIN.EXE verwenden, um dir anzuschauen, was eine DLL alles enthaelt.

http://embeddedguruji.blogspot.de/2015/ ... orial.html

Da kannst du ja sehen, ob dein "doppel" vorkommt. Ich wuerde da aber nicht die Luft anhalten.

[Sirius3]

In der von mir verlinkten StackOverflow-Antwort wird eine statische C#-Funktion exportiert, weiß nicht, ob das mit VB auch geht, das ist ja in der Hinsicht sehr eingeschränkt. Klassen und Klassemethoden kann man, wie schon geschrieben, auf diese Weise nicht benutzen.

[reinerdoll]

auch auf die gefahr hin, daß einer schimpft weil das so off-topic ist : die grundlagen sind mir wichtig.

also nochmal nach ausführlicher recherche zu COM und .net :

COM war mit win3.1 der microsoft-standard für interprozesskommunikation im system. objektorientiert.
DCOM war dann die basis für ole und so, also vereinfacht gesagt COM auf tcp/ip ausgedehnt.
es war damals schon möglich, COM-objekte selber zu schreiben.
u.a. wegen security-problemen, aber auch weil einfach zu viele schräge ports nötig waren, hat sich COM nicht als allgemienstandard durchgesetzt. viele industrieableger ( opc da, profinet cba) sind deswegen in schwierigkeiten gekommen.

.net war dann die antwort, neben der reinen interprozesskommunikation (auf soap umgestellt) kommt damit dann auch eine große plattform für softwareentwicklung, vor allem eine riesen klassenbibliothek für systemnahe programmierung. dazu sprachen, deren compiler (oder interpreter) keinen klassichen objectcode erzeugen, sondern auf laufzeitumgebungen (clr) zielen.

-> richtig oder bodenloser quatsch ??

[__deets__]

Nicht Quatsch, aber auch nicht ganz richtig. DCOM hat mit OLE AFAIK nix zu tun, dafür reicht COM. Und das .NET nun so speziell eine Antwort auf DCOM war - das bezweifele ich auch. Klar, es sollte in vielen Beziehungen ein Neuanfang sein. Aber ich glaube da haben andere Aspekte überwogen. Und was das mit Profinet zu tun hat erschließt sich mir nicht so, aber da bin ich auch weit weg von.

[reinerdoll]

wenn in word ein serienbrief geschrieben wird (wurde, mit com) und die adressen aus nem sql-server kommen, dann brauchts dcom, um über tcpip zugreifen zu können.

profinet cba basiert im kommunikationskern auf dcom, genau wie opc da.
man liest, daß die beiden wegen der abkündigung von dcom tot sind.
die reaktion in opc war dann die spezifikation von opc ua, basierend auf soap(xml) oder binary tcpip.

im wesentlichen gehts mir auch darum, keinen blödsinn zu reden, wenns um .net und com geht :

com als ipc und dann auch als standard für win-programmierung, objektorientiert mit wmi, adsi und so als klassenbibliotheken.

.net als neuer standard für ipc, auf soap basierend, und dazu ne mächtige plattform für programmierung. mit laufzeitsystemen und fetten klassenbibliotheken und eigenen sprachen.

[__deets__]

Dein erster Satz stimmt nicht. Die Verbindung zu einem SQL-Server geschieht zwar ueblicherweise ueber IP, aber mit DCOM hat das noch lange nix zu tun. Theoretisch kann man natuerlich eine Datenbank per DCOM anbinden. Fuer alles ausser MsSQL ist das aber 100%ig nicht so. Und selbst da ist es denke ich auch nicht so, denn ODBC hat mit DCOM auch erstmal nichts zu tun.

Insofern bleibe ich dabei: OLE hat mit DCOM per se nix zu tun. Da DOCM transparent sein soll zu COM kann man sich vielleicht irgendwas ausdenken, bei dem man seine Komponente per DCOM hochfaehrt/anspricht. Aber das ist bestimmt nicht ueblich. Jedenfalls fuer OLE. Fuer andere Dienste wie MS Workflow Services (oder wie die heissen) mag das alles anders sein.

.NET als neuer Standard fuer IPC ist mir auch wieder etwas seeeehr stark auf einen kleinen Teilaspekt abgestellt. Eher wird andersrum ein Schuh draus: .NET ist eine neue Laufzeitumgebung mit diversen Sprachen, und fuer IPC hat man auch da auf was neues gesetzt.

Uebrigens IMMER einen Blick wert ist zu dem Thema SOAP das hier: http://harmful.cat-v.org/software/xml/soap/simple

Wir sind hier aber auch schon ziemlich bei den Korinthen Im groben stimmt das schon alles.

[reinerdoll]

danke !