Installer - Primäre Ausgabe: Falsches Framework

Hallo zusammen,

ich habe einen Dienst, welcher über ein Pluginsystem erweitert werden kann.
Ein paar Plugins werden standardmäßig mitgeliefert, weshalb ich deren Ausgabe direkt in das Zielverzeichnis referenzieren möchte.

Kurz einen Installer gebaut, den Dienst und alle Abhängigkeiten hinzugefügt und den Plugin-Ordner erstellt.
Dann dort die "Primäre Ausgabe" der Plugins eingefügt.

Er wird alles "korrekt" installiert, der Dienst stürzt beim laden der Plugins jedoch ab.
Nach etwas debuggen & recherchieren ist mir aufgefallen, dass immer das Verzeichnis "\obj\Release*netcoreapp3.1*\Plugin.dll" verwendet wird.
Da der Dienst auf 4.7.2 läuft, müsste er natürlich entsprechend "\obj\Release*net472*\Plugin.dll" verwenden. Es werden auch immer beide dll´s erzeugt.
Allerdings finde ich aktuell keine Einstellung, wie ich das ändern kann.

Der Installer hat sog. Launch Conditions, dort sind tatsächlich ".Net Core" und ".Net Framework" enthalten. Die kann ich aber weder entfernen, noch anders sortieren.

Eine Alternative wäre natürlich eine harte Referenzierung, das wäre aber nur mein letztes Mittel. Wobei diese dann automatisch alle Abhängigkeiten mit in das Zielverzeichnis kopiert, was auch nicht richtig wäre...

Warum liegt das Plugin überhaupt in einem Build Target Ordner?
Das hört sich für mich nach einem Fehler in Deinem Pluginsystem so an, dass Dein Pluginsystem an einer Stelle Plugins erwartet, wo sie nicht liegen sollten / der Ordner für andere Dinge "reserviert" ist.
Warum liegen Deine Plugins nicht in einem dafür geeigneten / extra Ordner.

Es gibt eine Projektmappe, welche (vereinfacht) aus folgenden Komponenten besteht:

• Service
• Plugin1
• Plugin2
• Plugin3
• Installer

Der Installer referenziert die primäre Ausgabe des Service und allen Abhängigkeiten.
Nun sollen Plugin1 und Plugin2 standardmäßig mit ausgeliefert werden.
Entsprechend erzeugt der Installer ein Unterverzeichnis für die Plugins. Dort wird ebenfalls pro Plugin die primäre Projektausgabe referenziert.
Bisher aus meiner Sicht nichts ungewöhnliches oder "reserviertes".

Die Plugins haben allerdings als Targetframework* (warum auch immer, sie stammen ursprünglich nicht von mir)

netcoreapp3.1;net472

hinterlegt. Und das führt dazu, dass eben zwei Kompilate erzeugt werden:* \obj\Release\netcoreapp3.1\Plugin1.dll

• \obj\Release\net472\Plugin1.dll

und als "primäre Ausgabe" referenziert der Installer automatisch die DLL aus dem "netcoreapp3.1"-Verzeichnis.
Damit kann der .net 4.7.2 Dienst natürlich nichts anfangen.

Aktuell habe ich anstelle dieser "primären Ausgabe", direkt die richtige DLL als Klassenbibliothek eingebunden. Dann geht´s, ist aber alles andere als sauber.
Vorallem, wenn man während der Entwicklungsphase auch mal den Dienst und alle Abhängigkeiten + Plugins als Debug installieren möchte.

*Das Targetframework mit beiden Zielen ist strange. Egal welche Art von Klassenbibliothek ich erstelle, ich habe das Framework, Standard oder Core. Nie eine Mehrfachauswahl!
Selbst wenn ich die csprj anpasse, sagt Visual Studio dann "unsupported". Keine Ahnung welcher Typ von Projekt das ist 😕

*Das Targetframework mit beiden Zielen ist strange. Egal welche Art von Klassenbibliothek ich erstelle, ich habe das Framework, Standard oder Core. Nie eine Mehrfachauswahl!

Das hat einen Grund und ist prinzipiell erstmal völlig valide, siehe [FAQ] Das .NET Ökosystem - .NET, .NET Core, .NET Standard, NuGet und Co

Für die Angabe einer Runtime ist es TargetFramework, werden mehrere als Kompilat unterstützt ist es TargetFrameworks.
Basics: Target frameworks in SDK-style projects - .NET
Dass Visual Studio etwas mit "unsupported" quittiert ist meist das Resultat vom planlosen Editieren der csproj 😉

Warum das beim Pluginsystem bei euch so ist: kann auch hier seinen Grund haben. Wissen wir nicht.

Der Rest hört sich für mich nach einem reinen Konfigurationsproblem des Installers (und evtl ungünstliche Struktur des Pluginsystems, woher Plugins kommen) an. Welchen Du verwendest haste bisher leider nicht mit einem Wort verloren.
Üblicherweise können Installer multiple Runtime-Installs mitführen, in der Regel wird aber nur eine davon installiert (auf Basis von Configs und Conditions).
Daher kann ich Dir nur sagen: schau in die Doku des Installers.

Bisher aus meiner Sicht nichts ungewöhnliches oder "reserviertes".

Die Ordner bin/obj sind reservierte Ordner der lokalen Entwicklungsumgebung. Beides sind keine Quellen, die dafür gedacht sind, dass Assemblies in einem Installer landen.
Normalerweise würde man dafür den publish-Befehl verwenden, bei dem man dann einen spezifischen Ordner angibt, um die Artifacts abzulegen.
Publish apps with the .NET CLI - .NET

Der Installer kennt die Ordner nicht / sollte sie nicht kennen.