System.MissingMethodException bei Zugriff auf Dll-Funktionen

[dbfreak]

Hallo alle zusammen,

Umgebung: .Net 3.5, VB-Projekt

Ich habe eine zentrale Bibliothek in der globale Funktionen abgelegt werden erstellt und als dll in eine neue Applikation eingebunden.
Ich kann auf einzelne dll Funktionen zugegreifen-ohne Probleme. Nun musste ich in der "globalen" dll eine Funktion anpassen. Der Effekt ist nun folgender.
Wenn ich im Designmodus(Editor) auf die Funktion zugreife, funktioniert alles normal. Es werden die Parameter richtig angezeigt und so weiter. Es gibt auch keine Kompelierungsfehler.
In der Laufzeit kommt es dann aber zu dem Fehler:

Exception  Method not found:

Nach Recherche scheint es sich um einen System.MissingMethodException - Fehler zu handeln. MS schreibt, dass man mit einem starken Namen alles in Ordnung bringen kann.
Geht das auch anders? Ich habe in die globale Bibliothek noch andere dll's eingebunden. Da ist das Signieren nicht so lustig.

Danke für Hinweise

[Ralf Jansen]

Grundproblem ist das du vermutlich die erste Assembly mit einer Version der 2.ten kompilierst die diese Methode noch kennt zur Laufzeit aber eine andere verwendest die diese Methode nicht hat. Das Problem das man eine falsche Version der Assembly verwendet kann man durch Strong Naming verdeutlichen weil es dann entsprechend knallt wenn man das versucht (er findet die Assembly mit falscher Signatur einfach nicht) aber es behebt natürlich in keinerweise das Problem das du zur Laufzeit die falsche 2.te Assembly benutzt.

[dbfreak]

Ja natürlich muss das so sein. Aber mal abgesehen von verdeutlichen. Wenn ich in meiner neuen Assembly die Verweise auf die "globale" lösche. Dann die "globale" Ass. neu kompiliere. Anschließend alles neu einbinde. Warum geht es dann wieder schief? Das krieg ich einfach noch nicht klar im Kopf.

[Ralf Jansen]

Die Assembly die du referenzierst ist die die beim kompilieren benutzt wird um Abhängigkeiten zu prüfen. Es ist aber nicht zwingend die die auch zur Laufzeit benutzt wird. Je nachdem wo du die ~globale~ Assembly abgelegt hast wird eventuell eine andere Version zuerst gefunden und benutzt und dann knallt es zur Laufzeit. CTRL+D,M öffnet das Modules Windows das beim debuggen anzeigt welche Assembly von wo geladen wurden. Vielleicht gibt das einen Hinweis.

[dbfreak]

??
Wo soll ich den Tastencode absetzen Im Debugger bringt mir der Kollege, dass es den Befehl nicht gibt.

[Ralf Jansen]

Scheint einer dieser nicht sehr versionstabilen Shortcuts zu sein Unter 2013 ist es bei mir mittlerweile CTRL+ALT+U.
Im Menu aber immer unter Debug/Windows/Modules (oder das wie auch immer benannte deutschsprachige Äquivalent) wenn der Debugger in VS läuft.

[dbfreak]

Hallo R. Jansen,

also erstmal vielen Dank für die Geduld. Ich werde das auch noch testen.
Aber: Problem gelöst. Der Hintergrund war schon so wie beschrieben. Es wurde eine falsche Assembly gezogen. Die Falle habe ich mir selbst gebaut. Über eine verwaltete DLL im aufrufenden Programm wurde eine alte Version meiner globalen Assembly gezogen. Nach dem Löschen dieses Verweises hat sich dann alles aufgelöst. Ach ja, der ursprüngliche Fehler trat in einer nicht verwalteten DLL (dynamischer Aufruf) auf. In diesem Sinne

vielen Dank