2017-08-16 4 views
0

Ich arbeite an einer Win-Forms-Anwendung, die moduliert wird. Es gibt ein Basisprojekt, das die ausführbare Datei und mehrere Lösungen mit Formularen erstellt, die dem Programm beim Auffinden der DLL Funktionalität hinzufügen. Das Basisprojekt enthält auch ein Projekt, das als Vertrag für Formulare dient, die allgemeine Funktionen bereitstellen. Das Basisprojekt und das Formularprojekt werden von verschiedenen Teams gepflegt und ich suche nach einem guten Weg, Abhängigkeiten zwischen ihnen mit nugget zu handhaben.Launcher Exe in Nugget-Paket

Meine Idee ist, dass das Basisprojekt ein nugget-Paket erzeugt, das den Vertrag und alle Dateien enthält, die zum Starten des Programms benötigt werden. Auf diese Weise könnte ein Team, das mit einem Formular arbeitet, alle Dateien ausführen und ihre Formulare mit nuget testen. Um das Vertragsnuget hinzuzufügen, damit es als Referenz hinzugefügt wird, ist der einfache Teil. Das Problem ist, dass .exe und zusätzliche DLLs benötigt werden, um das Programm zu starten, aber nicht als Referenzen hinzugefügt werden.

Alternativen, über die ich nachdenke, sind - ein benutzerdefinierter Build-Schritt, der die Dateien aus dem nugget-Paketverzeichnis in das Ausgabeverzeichnis kopiert. - Hinzufügen von ihnen als contentFiles, die zum Ausgabeverzeichnis kopieren. - Tools-Ordner naht nicht zur Arbeit, da es nur in der Paketmanager-Konsole funktioniert.

der Suche nach Anregungen und Kommentare

Antwort

1

Sie können eine benutzerdefinierte .NuSpec Datei machen, mit was Inhalt, den Sie in der es wollen. Am Ende ist NuGet nur ein Archivierungsprozess, und Sie haben viel Freiheit bei der Arbeit daran.

Auch ich vermute, dass die Verwendung der EXE-Dateien innerhalb des Pakets erfolgt durch Schreiben von Befehlszeilenfolgen? Machen Sie statt dies zu tun eine Interface-Bibliothek, die den Benutzern exakte Funktionen bereitstellt und sie die exes über eine API aufrufen lässt? Dies verbessert auch die Fehlerbehandlung.