Ist LateBinding schlecht?

[Marko]

Hallo zusammen,

Ich bastle gerade an einer Plugin-basierten Applikation. In den Plugins
möchte ich jedoch auf viele Variabeln und Funktionen des Hauptprogramms
zugreifen - dazu übergeb ich dem Plugin einfach die entsprechenden Klassen.
Das klappt wunderbar, solange ich mit Option Strict Off arbeite. Ich hab
aber das Gefühl, dass Late-Binding irgendwie nicht gut sein kann ;)

Ein Interface machen für alle Variabeln und Funktionen ist sehr umständlich,
wenn man bedenkt, dass man schon mal 10 Plugins anpassen und neu kompilieren
muss, wenn man das Hauptprogramm um eine wichtige Funktion erweitert.

Wie soll man das also angehen, Latebinding benutzen, gibts noch etwas
anderes, oder hab ich das System der Interfaces noch nicht ganz begriffen?

Vielen Dank & Grüsse,
Marko

[Thomas Scheidegger [MVP]]

Hallo Marko

Post by Marko
aber das Gefühl, dass Late-Binding irgendwie nicht gut sein kann ;)
Ein Interface machen für alle Variabeln und Funktionen ist sehr umständlich,
wenn man bedenkt, dass man schon mal 10 Plugins anpassen und neu kompilieren

Late-Binding (oder auch Reflection) sind nicht immer 'schlecht',
sondern haben einfach (erst zu Laufzeit) zusätzliche Risiken.
(Fehler, welche sonst schon der Compiler reklamiert)


Evtl. kannst du ja auch eine Mischung machen,
Interfaces für alle bekannten, elementaren Methoden,
und Late-Binding für seltenere/optionale Methoden?

[Marko]

Hi,

Post by Thomas Scheidegger [MVP]
Late-Binding (oder auch Reflection) sind nicht immer 'schlecht',
sondern haben einfach (erst zu Laufzeit) zusätzliche Risiken.
(Fehler, welche sonst schon der Compiler reklamiert)

Mit denen kann man leben ;)

Post by Thomas Scheidegger [MVP]
Evtl. kannst du ja auch eine Mischung machen,
Interfaces für alle bekannten, elementaren Methoden,
und Late-Binding für seltenere/optionale Methoden?

Hmm ja, so hab ich es auch angefangen. Nur frage ich mich eben über die
"Gültigkeit" von Latebinding.
In C# z.B. gibt es das gar nicht (ich arbeite mit VB)
Ausserdem würde ich sonst gerne Option Strict programmieren, aber der
verbietet mir eben das späte Binden.

Gruss, Marko

[Thomas Scheidegger [MVP]]

Post by Marko
Ausserdem würde ich sonst gerne Option Strict programmieren, aber der
verbietet mir eben das späte Binden.

Option Strict wirkt AFAIK doch pro Source-Datei?

Ansonst evtl, falls strenge Trennung im ganzen Projekt gewünscht:
Den Code rund um Late-Binding in ein separates
DLL-Assembly - Projekt auslagern?

[Marko]

Hi,

Post by Thomas Scheidegger [MVP]
Option Strict wirkt AFAIK doch pro Source-Datei?

Ja, aber ich habs Projektweit aktiviert in den Einstellungen.

Post by Thomas Scheidegger [MVP]
Den Code rund um Late-Binding in ein separates
DLL-Assembly - Projekt auslagern?

Das Plugin an sich ist ja schon eine DLL, das reicht ;) Ich glaube, ich
werde einfach Option Strict deaktivieren..

Gruss, Marko

[Roland Weisskopf]

Post by Marko

Post by Thomas Scheidegger [MVP]
Option Strict wirkt AFAIK doch pro Source-Datei?

Ja, aber ich habs Projektweit aktiviert in den Einstellungen.

Spielt keine Rolle
Die Zeile OPTION STRICT OFF in einem
Klassenmodul etc. hebt die Standard-
Einstellung für die Funktionen im
betreffenden Modul auf.

Ich zieh immer alles was späte Bindung
benötigt in ein separates Dokument und
setz nur dort späte Bindung ein.

[Frank Dzaebel]

Hallo Marko,

In C# z.B. gibt es kein Latebinding (ich arbeite mit VB)

Das ist falsch. Es ist in VB.NET nur "bequemer".
In C# (und im gesamten .NET Framework) kann man späte Bindung
ganz normal durchführen (Reflection, Activator.CreateInstance, P/Invoke).
VB hat bei der impliziten späten Bindung "eingebaute" Helfer-
Funktionen (nutzen Reflection), aber machbar ist das alles in C#.
VB.NET "unterstützt" die (implizite) späte Bindung besser als C#.
Krasses Beispiel ist die GetObject-Funktion bei COM-Objekten.
Da muss man in C# schon PInvoke für bemühen.


Latebinding hat aber 2 klassische Nachteile : Performance und Aufwand
- Es ist wesentlich langsamer als frühe Bindung.
- Es ist immer mit einem Mehraufwand verbunden.

Ausserdem würde ich sonst gerne Option Strict programmieren, aber der
verbietet mir eben das späte Binden.

Nein, Du kannst mit "Option Strict" auch späte Bindung benutzen.
Nur musst Du dann die Variable "as Object" deklarieren und die
Member über InvokeMember(..) aufrufen.
Tatsächlich sind aber einige MS-Artikel bzgl. Latebinding missverständlich.

Einige Hintergründe zum Thema VB-und C#.NET Latebinding :
http://msdn.microsoft.com/library/DEU/cpguide/html/cpcondynamicallyloadingusingtypes.asp
http://download.microsoft.com/download/visualstudionet/document/1.0/win98mexp/en-us/vbcsharpwp.exe


ciao Frank
--
Dipl.Inf. Frank Dzaebel [MCP C#]
http://Dzaebel.NET

[Herfried K. Wagner [MVP]]

Hallo Frank!

Post by Frank Dzaebel
Krasses Beispiel ist die GetObject-Funktion bei COM-Objekten.
Da muss man in C# schon PInvoke für bemühen.

Reicht da nicht ein Verweis auf "Microsoft.VisualBasic.dll"?

[Frank Dzaebel]

Hallo Herfried,

Post by Herfried K. Wagner [MVP]

Post by Frank Dzaebel
Da muss man in C# schon PInvoke für bemühen.

Reicht da nicht ein Verweis auf "Microsoft.VisualBasic.dll"?

sicherlich, wenn man sich den Initial-Load-Overhead leisten kann ...
Es hat auch den Vorteil, dass die Interop-Assembly-Klasse im
Debugger zur Verfügung steht.

[C# - Beispiel]
object w = Microsoft.VisualBasic.Interaction.GetObject("",
"Word.Application");

ciao Frank
--
Dipl.Inf. Frank Dzaebel [MCP C#]
http://Dzaebel.NET

[Mark Doerbandt]

Hallo, Frank,

Post by Frank Dzaebel

Post by Herfried K. Wagner [MVP]
Reicht da nicht ein Verweis auf "Microsoft.VisualBasic.dll"?

sicherlich, wenn man sich den Initial-Load-Overhead leisten kann ...

Kannst Du diesen Overhead beziffern?

Gruss - Mark

[Frank Dzaebel]

Hallo Mark,

Post by Mark Doerbandt

Post by Frank Dzaebel

Post by Herfried K. Wagner [MVP]
Verweis auf "Microsoft.VisualBasic.dll"?

sicherlich, wenn man sich den Initial-Load-Overhead leisten kann ...

Kannst Du diesen Overhead beziffern?

Etwa 15 Millisekunden auf handelüblichen Rechnern gegenüber
einer C#-Anwendung ohne VB-Runtime.
Dazu kommt der zusätzlich ge'JIT'tete Code-Speicher der belegt wird.
Unter .NET 2.0 wird das noch mehr an Speicher werden,
aber gerade beim Dependant Assembly Loading werden dort
Performance-Verbesserungen eintreten (->ngen).

Ich spreche aber nur eine sehr kleine Menge von Applikations-Typen
an, bei denen das wirklich eine Rolle spielt.


ciao Frank
--
Dipl.Inf. Frank Dzaebel [MCP C#]
http://Dzaebel.NET

[Mark Doerbandt]

Hallo, Frank,

Post by Frank Dzaebel
Etwa 15 Millisekunden auf handelüblichen Rechnern gegenüber
einer C#-Anwendung ohne VB-Runtime.

OK, das ist ja noch akzeptabel.

Post by Frank Dzaebel
Dazu kommt der zusätzlich ge'JIT'tete Code-Speicher der belegt wird.
Unter .NET 2.0 wird das noch mehr an Speicher werden,

Gut, mir ging es um die Zeit.

Post by Frank Dzaebel
ciao Frank

Danke - Mark

[Herfried K. Wagner [MVP]]

Hallo Frank!

Post by Frank Dzaebel

Post by Herfried K. Wagner [MVP]

Post by Frank Dzaebel
Da muss man in C# schon PInvoke für bemühen.

Reicht da nicht ein Verweis auf "Microsoft.VisualBasic.dll"?

sicherlich, wenn man sich den Initial-Load-Overhead leisten kann ...

Millionen von VB.NET-Anwendungen können sich den leisten :-).

[Harald M. Genauck]

Hallo Frank,

Post by Frank Dzaebel
Latebinding hat aber 2 klassische Nachteile : Performance und Aufwand
- Es ist wesentlich langsamer als frühe Bindung.
- Es ist immer mit einem Mehraufwand verbunden.

In VB.NET ist dieser Merhaufwand aber eben marginal.

Viele Grüße

Harald M. Genauck

ABOUT Visual Basic - das Webmagazin
http://www.aboutvb.de

[Marko]

Hi,

Post by Frank Dzaebel
Latebinding hat aber 2 klassische Nachteile : Performance und Aufwand
- Es ist wesentlich langsamer als frühe Bindung.
- Es ist immer mit einem Mehraufwand verbunden.

Mit dem Zeitverlust kann ich leben wahrscheinlich leben.
Mehraufwand inwiefern? Keine Intellisenseunterstützung mehr? ;)

Post by Frank Dzaebel

Post by Marko
Ausserdem würde ich sonst gerne Option Strict programmieren, aber der
verbietet mir eben das späte Binden.

Nein, Du kannst mit "Option Strict" auch späte Bindung benutzen.
Nur musst Du dann die Variable "as Object" deklarieren und die
Member über InvokeMember(..) aufrufen.

Ach herrje, ist das mühsam mit InvokeMember :S

Danke,
Marko

[Frank Dzaebel]

Hallo Marko,

Post by Marko

Post by Frank Dzaebel
Latebinding hat aber 2 klassische Nachteile : Performance und Aufwand
- Es ist wesentlich langsamer als frühe Bindung.
- Es ist immer mit einem Mehraufwand verbunden.

Mit dem Zeitverlust kann ich leben wahrscheinlich leben.
Mehraufwand inwiefern? Keine Intellisenseunterstützung mehr? ;)

Ok, das auch, aber hauptsächlich die Notwendigkeit die Typen und
Methoden zu beschaffen, und über Reflection, etc. aufzurufen.
Dieser Mehraufwand wird in VB.NET schon durch die Helfer-Funktionen
nach aussen extrem reduziert. Er existiert hier also mehr intern und wird
eher in Performance-Nachteilen gegenüber früher Bindung sichtbar.

Post by Marko

Post by Frank Dzaebel
Nein, Du kannst mit "Option Strict" auch späte Bindung benutzen.
Nur musst Du dann die Variable "as Object" deklarieren und die
Member über InvokeMember(..) aufrufen.

Ach herrje, ist das mühsam mit InvokeMember :S

Ja schon, für grössere Projekte zumindest. Nur, manchmal braucht man das
schon.
Und einmal verstanden, wirds mit dem Tippen auch schneller.


ciao Frank
--
Dipl.Inf. Frank Dzaebel [MCP C#]
http://Dzaebel.NET

[Marko]

Hi,

Noch schnell eine Frage:

Gibts in der resultierenden Assembly einen Unterschied, wenn ich Option
Strict deaktiviere, aber im Code durchgehend so programmiere, als wenn es
aktiviert wäre?


Gruss, Marko

[Herfried K. Wagner [MVP]]

Hallo Marko!

Post by Marko
Gibts in der resultierenden Assembly einen Unterschied, wenn ich Option
Strict deaktiviere, aber im Code durchgehend so programmiere, als wenn es
aktiviert wäre?

Nein.

[Marko]

Hi Herfried,

Post by Marko
Gibts in der resultierenden Assembly einen Unterschied, wenn ich Option
Strict deaktiviere, aber im Code durchgehend so programmiere, als wenn es
aktiviert wäre?

Nein.

Das ist doch super ;) Dann könnte ich es deaktivieren und bequem
Late-Binding betreiben.

Ich hab jedoch noch eine andere Lösung gefunden und würde gerne wissen, was
Du davon hälst:

Ich definiere ein Interface, in dem nur eine Funktion definiert ist,
nämlich: Invoke(Name as string, args as object()) as object.
Über diese Funktion lässt sich indirekt alles aufrufen aus der
Hauptapplikation, was nötig ist (Variabeln, Funktionen, ...). Das hat den
Vorteil, dass wenn ich die Hauptapplikation um eine Kleinigkeit erweitere,
nur die Funktion Invoke() erweitern muss, und nicht etwa ein extern
definiertes Interface, was, wie gesagt, den grossen Aufwand mit sich bringen
würde, alle vorhandenen Plugins auch upzudaten.

Wie würdest Du als Profi das ganze angehen? Ist diese Lösung akzeptabel? ;)

Danke & Gruss,
Marko

[Frank Dzaebel]

Hallo NG,

Post by Frank Dzaebel
Krasses Beispiel ist die GetObject-Funktion bei COM-Objekten.
Da muss man in C# schon PInvoke für bemühen.

Bezgl. GetObject ist das falsch, was ich erzählt.
Man kann hier einfach
System.Runtime.InteropServices.Marshal.GetActiveObject(..) nehmen. Die
VB-Runtime liefert mit GetObject auch ein anderes Verhalten.
Durch Marshal.GetActiveObject kann man eine ausgeführte Instanz des
angegebenen Objektes aus der ROT (Running Object Table) bekommen.

ciao Frank
--
Dipl.Inf. Frank Dzaebel [MCP C#]
http://Dzaebel.NET