| |
VB.NET - FortgeschritteneVerschiedene Versionen eines Verweises für unterschiedliche Systeme | | | Autor: Soenke1492 | Datum: 02.05.17 19:16 |
| Hallo zusammen,
Folgende Problemstellung:
Es gibt eine Exe eines Systemanbieters, welche ich als Referenz eingebunden habe, um darüber das Gerät des Herstellers zu steuern (im konkreten Fall einen Laser).
Jetzt läuft die Software mit der Version 1.1 problemlos auf fünf Maschinen.
Jetzt wurden neue Maschinen angeschafft und der Hersteller des Lasers verwendet jetzt die Version 1.2.
Da diese Version nur mit einem teuren Firmware-Upgrade mit den alten Lasern kompatibel ist, bin ich gezwungen beide Versionen in der Software zu verwalten.
Wie kann ich das machen? Beide Exes haben den gleichen Dateinamen? Identifizieren könnte ich die richtige Datei über das Betriebssystem (64bit/32bit) oder den Computernamen ohne Probleme.
Der Verweis in der verwendenden Klasse erfolgt folgendermaßen:
Imports LaserControl Wäre super, wenn jemand helfen könnte. Ich möchte nicht auf Dauer zwei Versionen der gesamten Software pflegen müssen.
Danke und viele Grüße,
Sönke | |
Re: Verschiedene Versionen eines Verweises für unterschiedliche Systeme | | | Autor: Manfred X | Datum: 02.05.17 19:35 |
| [I]Es gibt eine Exe eines Systemanbieters, welche ich als Referenz eingebunden habe, ...[/I]
Was bedeutet das? Wie eingebunden? Ist es eine ActiveX-Exe?
Ich vermute, es handelt sich um eine Net- (oder ActiveX-) Bibliothek. | |
Re: Verschiedene Versionen eines Verweises für unterschiedliche Systeme | | | Autor: sv00010 | Datum: 04.05.17 19:05 |
| Soenke1492 schrieb:
Zitat: | |
Wie kann ich das machen? Beide Exes haben den gleichen
Dateinamen? Identifizieren könnte ich die richtige Datei über
das Betriebssystem (64bit/32bit) oder den Computernamen ohne
Probleme. | |
Das aktuelle Betriebssystem kann mit Environment.OSVersion ermitttelt werden.
https://msdn.microsoft.com/de-de/library/system.environment.osversion(v=vs.110).aspx | |
Re: Verschiedene Versionen eines Verweises für unterschiedliche Systeme | | | Autor: Manfred X | Datum: 04.05.17 20:53 |
| Hallo!
Falls es sich bei diesen Exe-Dateien um gültige Net-Assemblies handelt,
können sie eventuell zur Laufzeit durch System.Reflection.Assembly.Load(Pfad)
selektiv dynamisch dazugeladen werden. | |
Re: Verschiedene Versionen eines Verweises für unterschiedliche Systeme | | | Autor: Soenke1492 | Datum: 05.05.17 18:30 |
| Hallo Manfred,
entschuldigung für die späte Antwort.
Es ist eine Exe-Datei, welche ich autark ausführen kann. Wenn ich sie ausführe, dann öffnet das Programm und ich kann manuell den Laser ansteuern, Parameter ändern etc.
Ich habe diese Exe als Verweis in das Projekt eingefügt.
Jetzt gibt es eine Klasse "Laser", welche dann das Laserprogramm aufruft und mit der ich die Automation des Laservorgangs steuere (ich füge nur das wesentliche ein):
Imports LaserControl 'name der besagten Exe
Public Class Laser
Protected frmLaserControlMain As LaserControl.frmMain 'LaserControl.frmMain
' frmLaserControlMain = null; //Used to get access to the main form of
' LaserControl
Protected WithEvents frmLaserControl As LaserControl.frmLaserControl _
'LaserControl.frmLaserControl frmLaserControl = null; //Used to access
' the main user interface form
Public Sub Start() 'New()
Try
InitializeLaserControl()
Catch ex As Exception
MessageBox.Show(Convert.ToString(ex))
End Try
End Sub
Public Sub InitializeLaserControl()
Try
frmLaserControlMain = New LaserControl.frmMain() 'Laser-Software
' "MagigMark" starten
frmLaserControl = frmLaserControlMain.LaserControl
frmLaserControlMain.Show()
Catch ex As Exception
fehler(ex, "initializelasercontrol")
End Try
End Sub Jetzt ist mein Problem, dass ich defintiv auf einem 32-Bit-Rechner eine andere Lasercontrol-Exe aufrufen muss, als auf einem 64-Bit-Rechner.
Deshalb habe ich beide Exes aktuell als Verweise eingefügt. Die eine habe ich mit 32-Bit benannt.
Jetzt meckert aber zurecht Visual Studio, dass der Verweis auf Lasercontrol im Namespace nicht eindeutig ist.
Und zwar zuerst bereits in dieser Zeile
Protected frmLaserControlMain As LaserControl.frmMain 'LaserControl.frmMain
' frmLaserControlMain = null; //Used to get access to the main form of
' LaserControl Kannst Du helfen?
Viele Grüße,
Sönke | |
Beispiel: dynamische Nutzung einer Assembly zur Laufzeit (System.Reflection) | | | Autor: Manfred X | Datum: 05.05.17 22:25 |
| Prüfe zunächst, ob die Exe als Plugin (über eine gemeinsame Schnittstelle)
nutzbar ist.
Kleines Beispiel für die Nutzung einer Assembly zur Laufzeit per Reflection:
Es gibt eine "Exe", in der eine Klasse angesiedelt ist, die "FileCompare" heißt.
In dieser Klasse existiert eine Instanz-Methode "Compare", der als
erster Parameter ein Dateiname und als 2./3. Parameter ein Verzeichnis zu geben ist.
Die Methode prüft, ob diese Datei in beiden Verzeichnissen vorhanden und
identisch ist (diverse Vergleichs-Parameter).
Das Ergebnis wird als Enumeration "FileCompareResult" zurückgegeben.
'1. Den Pfad zur gewünschten Assembly festlegen.
Dim path as String = "......"
'2. Die gewünschte Assembly zur Laufzeit laden:
Dim myasm As System.Reflection.Assembly = _
System.Reflection.Assembly.LoadFile(path)
'optional: Auflistung aller Typen in der geladenen Assembly
Dim types() As System.Type = myasm.GetTypes
'3. Eine Instanz der gewünschten Klasse erstellen
Dim myfc As Object = myasm.CreateInstance("Assemblyname.FileCompare", True)
'eine Instanz der Rückgabe-Enumeration erstellen
Dim myfcr As Object = myasm.CreateInstance("Assemblyname.FileCompareResult", _
True)
'optional: Die Methoden der Klasse "FileCompare" auflisten
Dim methods() As Object = myfc.GetType.GetMethods()
'4. Eine Methoden-Info für den Zugriff auf die Instanz-Methode "Compare"
Dim myMethod As System.Reflection.MethodInfo = myfc.GetType.GetMethod("Compare")
'5. Die Liste der Parameter für einen Aufruf von "Compare" als Array
Dim parameters() As Object = {"Dokument_Link.rtf", "C:\daten1", "C:\daten2"}
'6. Die Methode mit den Parametern ausführen
'Dabei muß zunächst die Instanz der Klasse gegeben werden, in der sich die
'Methode befindet, danach die Parameter
myfcr = myMethod.Invoke(myfc, parameters) Wenn die Klasse sich in einem Namespace befindet, ist dieser zusätzlich anzugeben.
Beitrag wurde zuletzt am 05.05.17 um 22:35:14 editiert. | |
Re: Verschiedene Versionen eines Verweises für unterschiedliche Systeme | | | Autor: Manfred X | Datum: 05.05.17 22:46 |
| Kannst Du nicht Projekt-Verweise auf beide Assemblies setzen und
eine "Selector"-Klasse erstellen, die je nach Parametervorgabe
Klassen der einen oder der anderen Assembly intern verwendet?
Von aussen - also in deinem übrigen Programm - werden dann nur
Instanzen dieser Selectorklasse genutzt.
Du kannst auch zwei Wrapper-DLL erstellen, z.B. W32 und W64
Jede DLL greift intern auf eine EXE zu (je ein Projektverweis) und
stellt die EXE-Klassen extern als eigene Klassen zur Verfügung (Kapselung).
In Deinem HauptProjekt kannst Du auf beide DLLs verweisen. Sie besitzen
unterschiedliche Namen und Namespaces.
Und prüfe, ob Du berechtigt bist, Klassen aus einem Fremd-Programm
in einer eigenen Anwendung zu nutzen.
Beitrag wurde zuletzt am 05.05.17 um 23:03:51 editiert. | |
Re: Verschiedene Versionen eines Verweises für unterschiedliche Systeme | | | Autor: Soenke1492 | Datum: 05.05.17 23:22 |
| Hast Du ein ganz kurzes Beispiel für die zwei Wrapper-Dlls W32 und W64?
Das klingt gerade vielversprechend.
Erstelle ich die in einer Extra-Solution?
Verwenden darf ich die Laser-Exes auf jeden Fall, da wir die Laserlizenzen erworben haben.
Viele Grüße,
Sönke | |
Re: Verschiedene Versionen eines Verweises für unterschiedliche Systeme | | | Autor: Soenke1492 | Datum: 05.05.17 23:35 |
| Ok, also die DLL habe ich inzwischen erstellen können und auch im Ursprungsprojekt eingebunden.
Aber wie schleife ich die Methoden aus der ursprünglichen Exe am besten durch? | |
Re: Verschiedene Versionen eines Verweises für unterschiedliche Systeme | | | Autor: Manfred X | Datum: 05.05.17 23:39 |
| Du erstellst zwei neue Projekte des Typs Klassenbibliothek.
In jedem Projekt setzt Du einen Verweis auf eine der EXE-Dateien.
Ob Du das in einer Extra-Solution oder innerhalb Deiner bereits
vorhandenen Projektmappe erledigst, spielt eigentlich keine Rolle.
In Deinem Anwendungsprojekt setzt Du nur Verweise auf diese DLLs.
Für jeden Namespace und jede Klasse der EXE erstellst Du eine entsprechende
öffentliche Klasse mit Methoden, Eigenschaften usw. in der DLL.
Dort richtest Du die entsprechenden Instanzen der EXE-Klassen ein
und leitest die an die DLL jeweils gegebenen Methoden-Parameter oder
Eigenschaftenwerte an die entsprechneden EXE-Methoden/Eigenschaften weiter
bzw. gibst Byref-Params/Methoden-Rückgaben der EXE zurück.
Ich will ja nicht unken, aber die Lizenz für die Nutzung eines Steuerungs-
Programms im Rahmen eines Hardware-Pakets schließt nicht unbedingt die Nutzung
der Software in einer eigenen Programm-Umgebung ein.
Freigegebene Software-Bestandteile werden gewöhnlich als Bibliotheken (Plugins)
oder Treiber geliefert. Es sind ggf. auch Haftungsfragen zu klären, z.B. wenn Dein
Programm per Nutzung der Klassen dieser Exe-Dateien irgendwelche Beschädigungen
verursacht.
zurück. | |
Re: Verschiedene Versionen eines Verweises für unterschiedliche Systeme | | | Autor: Manfred X | Datum: 05.05.17 23:53 |
| So pauschal läßt sich das nicht beantworten.
Formular-Instanzen erstellst Du in der DLL und legst dort
für Dein Anwendungsptogramm nur die Eigenschaften und Methoden
als öffentliche Properties, Functions, Sub offen, die für die
Kommunikation benötigt werden.
Ereignisse des Formulars verarbeitest Du in der DLL und rufst
Ereignisse auf, die in der DLL deklariert sind. Durch die gibst Du
ggf. Ereignisparameter weiter (im RaiseEvent innerhalb der DLL). | |
| Sie sind nicht angemeldet! Um auf diesen Beitrag zu antworten oder neue Beiträge schreiben zu können, müssen Sie sich zunächst anmelden.
Einloggen | Neu registrieren |
|
|
Neu! sevPopUp 2.0
Dynamische Kontextmenüs!
Erstellen Sie mit nur wenigen Zeilen Code Kontextmenüs dynamisch zur Laufzeit. Vordefinierte Styles (XP, Office, OfficeXP, Vista oder Windows 8) erleichtern die Anpassung an die eigenen Anwendung... Weitere InfosTipp des Monats Access-Tools Vol.1
Über 400 MByte Inhalt
Mehr als 250 Access-Beispiele, 25 Add-Ins und ActiveX-Komponenten, 16 VB-Projekt inkl. Source, mehr als 320 Tipps & Tricks für Access und VB
Nur 24,95 EURWeitere Infos
|