Laden...

Assembly sucht seine Verweise in komischen Verzeichnis

Erstellt von Vassili vor 16 Jahren Letzter Beitrag vor 16 Jahren 1.725 Views
Vassili Themenstarter:in
187 Beiträge seit 2005
vor 16 Jahren
Assembly sucht seine Verweise in komischen Verzeichnis

Hallo leute,

komischer Titel komisches Problem und ich bräuchte euer Brain.

ich habe zwei Assemblies (Add-Ins für ein von mir geschriebenes Programm), die jeweils einen Verweis auf ein anderes Projekt haben (Dieses Standard Add-In Projekt hat standard Funktionen für Add-Ins, nennen wir es AddInBase). In jeder Assembly gibt es eine AddIn Klasse die von einer AddInBase-Klasse erbt. Diese AddInBase-Klasse befindet sich im AddInBase Projekt.

Also Add-In 1 hat eine Assembly der AddInBase als Verweis mit der Version 1.0. Add-In 2 hat eine Assembly der AddInBase als Verweis mit der Version 1.1, da die AddInBase für das zweite Add-In erweitert werden musste.

Diese Add-Ins sollen nun von meiner Anwendung geladen werden und das funktioniert auch prima. Die Addins findet die Anwendung in einem Unterverzeichnis. hier kurz dargestellt:
Anwendung
--> Unterverzeichnis "Add-Ins"
------> Unterverzeichnis "Add-In 1"
----------> Datei "Add-In 1.dll" Version 1.0
----------> Datei "AddInBase.dll" Version 1.0
------> Unterverzeichnis "Add-In 2"
----------> Datei "Add-In 2.dll" Version 1.0
----------> Datei "AddInBase.dll" Version 1.1

Meine Anwendung findet auch prima via Reflection die Add-In 1 und Add-In 2, erkennt die als Add-In, ignoriert die AddInBase, da es keine AddIns sind und möchte die auch laden. Also erstellt es instanzen der AddIn Klasse in den jeweiligen Add-In DLL's. Diese AddIn Klassen sind ja wie gesagt von einer AddInBase-Klasse der AddInBase.dll abgeleitet. Dabei wurde die in der Version 1.1 erweitert um eine Eigenschaft, welche im Konstruktor der AddIn Klasse der Add-In 2.dll gesetzt wird.

Zurück zur Anwendung, die instanzen erstellt. Sobald die Anwendung eine Instanz der AddIn Klasse erstellen will schmiert mir die Anwendung ab aus unerklärlichen gründen.

Ich hab beim hin und her probieren herausgefunden, dass die Add-In 2.dll, die ja den Verweis auf die AddInBase.dll mit der Version 1.1 hat, die AddinBase.dll aus dem Verzeichnis der Add-In 1.dll mit der Version 1.0 läd. Da diese aber die Eigenschaft nicht hat, schmiert mir die Anwendung schon im Konstruktor ab mit der Fehlermeldung, dass der die Eigenschaft in der Assembly nicht finden kann.

Nun zu meinem Problem. Wie kann es sein, dass meine Assembly seine Verweise in einem Nachbarverzeichnis sucht und diese bevorzugt und nicht die Verweise aus dem eigenen Verzeichnis?

--- Edit

Ich habs total verplant. Im GUI-Technologien Forum bin ich falsch. Könnte jemand diesen Thread ins passende Forum verschieben?

2.187 Beiträge seit 2005
vor 16 Jahren

So weit ich das sehe:
Wird dein AddIn auf Basis von Version 1.0 zuerst geladen. Daher befindet sich Basi-Version1.0 im speicher. Fordert das AddIn auf Basis von Version1.1 nun die Basisklasse an (OHNE VERSION), wird bevorzugt die Klasse aus dem Speicher verwendet und garnicht mehr nach irgend welchen DLLs auf der Platte gesucht.

Einfache Lösung: Kopier die neuste Version der DLL ins ausführungsverzeichniss. Diese DLLs werden immer bevorzugt geladen (glaub ich zumindest 🤔 ).

Gruß
Juy Juka

830 Beiträge seit 2005
vor 16 Jahren

Hallo Vassili,

wieso überhaupt eine andere Version. Eine Erweiterung führt doch (eigentlich) nie zu einem Bruch der Kompatibilität.

Gruss
Friedel

Ohne Ziel ist auch der Weg egal.

2.187 Beiträge seit 2005
vor 16 Jahren

Darum auch nur eine erhöhung der Miner-Version (1.0.0.0 -> 1.1.0.0).
Gäb es einen "Bruch", müsset man die Major-Version erhöhen (1.0.0.0 -> 2.0.0.0)

830 Beiträge seit 2005
vor 16 Jahren

Dann sollten auch keine Probleme auftreten, wenn nur die neue Version geladen wird.

Ohne Ziel ist auch der Weg egal.

2.187 Beiträge seit 2005
vor 16 Jahren

Stimmt schon, nur wird halt leider Version 1.0.0.0 geladen, weil kein Assembly im Ausführungsverzeichniss liegt.

830 Beiträge seit 2005
vor 16 Jahren

Version 1.0 ganz weglassen, keinen Unterordner, keine DLL im Ausführungsverz., nirgends einfach löschen.

Ohne Ziel ist auch der Weg egal.

2.187 Beiträge seit 2005
vor 16 Jahren

Ist möglich (und sauberer), hauptsache ist jedoch Version1.1.0.0 im Ausführungs-Verzeichniss.

Vassili Themenstarter:in
187 Beiträge seit 2005
vor 16 Jahren

Original von Friedel
Hallo Vassili,

wieso überhaupt eine andere Version. Eine Erweiterung führt doch (eigentlich) nie zu einem Bruch der Kompatibilität.

Gruss
Friedel

Weil Add-In 1 mit der Basis DLL in der Version 1.0 kompiliert ist. Während der Zeit des Releases von Add-In 2 wurde die Basis DLL verändert. deswegen 1.1 Die DLL wurde um eine Funtkion erweitert.

Vassili Themenstarter:in
187 Beiträge seit 2005
vor 16 Jahren

Von was für einem Ausführungs Verzeichnis redet ihr? wo die anwendung drin ist?

2.187 Beiträge seit 2005
vor 16 Jahren

Es giebt nur ein Ausführungsverzeichniss, welches ist im Standardfall das Verzeichniss ist, in dem die *.exe liegt.

Unter Windows kann eine *.exe auch mit einem anderen Ausführungsverzeichniss gestartet werden aber frag mich nicht wie!

Vassili Themenstarter:in
187 Beiträge seit 2005
vor 16 Jahren

spitze, wenn ich die dll ins ausführungsverzeichnis packe dann hab ich ja total die probleme die verschiedenen versionen der addinbase.dll zu unterscheiden. was mach ich, wenn die version 1.1 keine erweiterung sondern eine änderung einer funktion hat?????? außerdem will doch das addin 1 nicht die version 1.1 des addinbase haben... der will doch genau die version haben mit der es kompiliert wurde

2.187 Beiträge seit 2005
vor 16 Jahren
  1. Das AddIn1 überprüft nur die Major-Versionsnummer (die erste der 4 Zahlen).
    => AddIn1 läuft auch mit Version 1.1

  2. Wenn es eine Änderung einer Bibliothek gibt, durch die Sie nicht abwärstkompartiebel wird, muss man die Major-Versionsnummer ändern (1.x.x.x -Auf-> 2.x.x.x) und die Klassen, die auf der alten Version beruhen müssen über arbeitet werden.
    => Version 1 und Version 2 sind NICHT kompartiebel.

Alternativ kannst du deine Bibliothken auch im GAC installieren, der Side-By-Side-Versionen erlaubt (d.h. Mehrer Versionen gleichzeitig). Dabei muss halt wieder der unterschied Major/Minor-Versionsnummer beachtet werden !! (1.1 überschreibt 1.0 ; 2.0 läuft parallel zu allen 1.x Versionen).

Vassili Themenstarter:in
187 Beiträge seit 2005
vor 16 Jahren

AddIn1 läuft laut auch mit Version 1.1 der AddIn.dll
AddIn2 sollte dies aber nicht tun. Warum sollte der die version 1.0 des addin1 verwenden? der tipp, dass dabei noch geguckt wird, ob die assembly im arbeitsspeicher ist und der deswegen diese bevorzugt klingt eigentlich garnicht so verkehrt und das werde ich heute noch überprüfen.

2.187 Beiträge seit 2005
vor 16 Jahren

Nur zum Verständniss:

AddIn1 verweist auf Basis Version 1.0?
AddIn2 verweist auf Basis Version 1.1?

Basis Version 1.1 ist 100% abwärtskompartibel zu Basis Version 1.0?

Richtig? ((Wenn 1.1 nich abwärstkompartibel zu 1.0 ist, dann ist die Versionsnummer falsch.))

Vassili Themenstarter:in
187 Beiträge seit 2005
vor 16 Jahren

das galileo open book sagt, dass bie einer änderung der nebenversionsnummer bereits festgelegt wird, dass es sich um eine nicht abwärtskompatible version handelt.

ich glaub eher, dass das geschmackssache ist, ob die version abwärtskompatibel ist oder nicht. daher würd ich nicht sagen, dass die versionsnummer falsch ist.

Ja noch ist sie abwärtskompatibel. meine überlegung war nur dass jedes addin seine eigene dll bekommen soll damit solche probleme mit einer abwärtskompatibilität nicht auftreten. die rahmenanwendung soll dann in der lage sein, die verschiedenen versionen zu unterscheiden, sollte es da einen unterschied geben.

2.187 Beiträge seit 2005
vor 16 Jahren

Dann bennen die DLLs doch einfach anders!!

Basis.dll (V1.0) wird Basis.1.DLL
Basis.dll (V1.1) wird Basis.2.DLL

Aber wenn du solche Änderungen an der Basisklasse hast, die die Hauptanwendung nicht betreffen, dann musst do dort eh noch was am Design ändern:

Dann muss die Funktion, die für AddIn1 und AddIn2 unterschiedlich ist in eine eigene Klasse/DLL und das Interface/die Basisklasse für ein AddIn muss ebenfalls getrennt sein.