Warum müssen meine Assemblies in einer bestimmten Reihenfolge geladen werden?

8

Ich schreibe ein einfaches Plugin und stolperte über contractType.IsAssignableFrom(pluginType) gibt unterschiedliche Ergebnisse zurück, abhängig von der Reihenfolge des Ladens.

Der Aufruf von IsAssignableFrom im Plugin gibt True wie erwartet zurück.
Aber wenn ich die Contract-Assembly laden bevor das Plugin IsAssignableFrom im Plugin lädt gibt False zurück.

Ich benutze Win10 und dotnet4.7, aber ich bezweifle, dass das relevant ist.

Code

%Vor%

Um das Testen zu erschweren:
Wenn ich den LoadingContractAndThenPlugin_Fails -Test selbst durchführe, scheitert es. Aber wenn ich die Tests zusammen benutze, ist es abhängig von der Reihenfolge. Das Ausführen von SimplyLoadingPlugin_Succeeds first und LoadingContractAndThenPlugin_Fails last macht beide Tests grün, aber wenn sie in umgekehrter Reihenfolge ausgeführt werden, werden beide Fehler ausgeführt.
Irgendwie hat das Laden von Contract before Plugin etwas für mich angerichtet Ich kann nichts in Bezug auf die GAC sehen.

Im Folgenden finden Sie alle benötigten Dateien. Die Pfade müssen wahrscheinlich aktualisiert werden.
4 Projekt mit jeweils einer Datei. 1 Lösung.

Contract.cs (ein Bibliotheksprojekt)

%Vor%

Plugin.cs (ein Bibliotheksprojekt)

%Vor%

Tests.cs (ein Testprojekt)

%Vor%

Program.cs (ein Konsolenprojekt)

%Vor%     
LosManos 09.08.2017, 10:28
quelle

2 Antworten

9

Wenn Sie Contract mit Assembly.LoadFrom laden, erstellen Sie eine Referenzmehrdeutigkeit. Diese Bibliothek ist bereits geladen, deshalb können wir typeof(Contract) nicht erneut laden ...

Meine Empfehlung: Verwenden Sie die Reflektion, um festzustellen, welche Referenzen Sie haben, und laden Sie nur diejenigen, die noch nicht vorhanden sind. Hier ist ein Beispielcode-Snippet:

%Vor%

In diesem Beispiel erhalten wir jede DLL für ein bestimmtes Verzeichnis (Unterverzeichnisse eingeschlossen), das Verzeichnis kann ein relativer Pfad sein wie ..\..\.. und nur diejenigen laden, die nicht bereits in den Assembly-Referenzen enthalten sind.


Und hier ist die vollständige Lösung mit zwei Plugin-Projekten:
Ссылка

    
HelderSepu 14.08.2017 19:02
quelle
1

Wie @HelderSepu behauptete, könnte das Laden der Vertragsassemblierung ein zweites Mal das Problem sein.

Ich würde vorschlagen, dass Sie auf eine andere, aber einfachere Art und Weise testen. Anstatt die Baugruppen in den Tests manuell (erneut) zu laden, fügen Sie einfach Verweise zu den Assemblys / Projekten im Testprojekt hinzu und verweisen direkt auf typeof(Contract) und typeof(Plugin) und prüfen, ob typeof(Contract).IsAssignableFrom(typeof(Plugin)) . Nichts kompliziertes, fügen Sie einfach die Referenzen zum Testprojekt hinzu.

Sie müssen nicht testen, ob die Assembly korrekt geladen ist, die CLR wird das verarbeiten. Sie müssen testen, ob die Plugin-Assembly eine Contract -Definition enthält. Welche Anwendungsfälle auch immer Sie für Ihre Architektur haben mögen, es geht nicht darum, ob das Laden von Baugruppen funktioniert, worüber Sie sich Sorgen machen sollten. es ist, ob das Plugin korrekt implementiert wurde.

    
EvilTak 20.08.2017 07:40
quelle

Tags und Links