Ich habe eine Visual Studio-Lösung, die Folgendes enthält:
Das statusfreie Service-Projekt verwendet eine konfigurationsbasierte Abhängigkeitsinjektion, dh die Abhängigkeiten sind lose mit dem Projekt selbst gekoppelt und nicht mit den tatsächlichen "Projekt- / Kompilierungsabhängigkeiten" von VS.
Ich möchte weiterhin Visual Studios verwenden, aber wenn ich dieses Projekt veröffentliche, weiß es nichts über die Assembly-Abhängigkeiten (da diese nur in der DI-Konfiguration definiert sind) und deshalb packt es nicht die notwendigen Dateien und löst Ausnahmen aus, die versuchen, eine Abhängigkeitsinjektion durchzuführen.
Gibt es einen Weg in der ApplicationManifest.xml-Datei oder einer der anderen vielen XML-Dateien, die Visual Studios bietet, dass ich zusätzliche Dateien angeben kann (d. h. meine abhängigen Assemblies), die im Rahmen der Bereitstellung an Service Fabric veröffentlicht werden?
Im Idealfall möchte ich diese Datei automatisieren, damit sie als Teil meines automatisierten Build-Skripts generiert wird.
Um dieses Verhalten in das Service-Projekt selbst einzubetten, könnten Sie die Projektdatei des Service so bearbeiten, dass sie die MSBuild-Logik enthält, die & lt; Content & gt; Elemente für das Projekt, für die CopyToOutputDirectory auf "Always" oder "PreserveNewest" festgelegt ist. Diese Elemente werden zur Erstellungszeit basierend auf der Konfiguration Ihrer DI dynamisch einbezogen. Da das Serviceprojekt "deklariert", dass es diese Inhaltselemente hat, werden sie in den Paketordner des Dienstes kopiert.
Eine weitere Option ist das Hinzufügen von Logik im Anwendungsprojekt während des Paketschritts. Sie können ein Ziel dort wie folgt implementieren:
%Vor%Ihre Logik dort würde die gleiche Art von Lesen Ihrer DI-Konfiguration tun, aber anstatt & lt; Content & gt; Elemente, es würde einfach die Dateien an den entsprechenden Speicherort innerhalb des Anwendungspakets kopieren, dessen Pfad durch $ (PackageLocation) definiert ist.
Tags und Links azure c# dependency-injection azure-service-fabric