Laden...

Publishen von statischen Files in Unterprojekten funktioniert nicht

Erstellt von dannoe vor einem Jahr Letzter Beitrag vor einem Jahr 700 Views
D
dannoe Themenstarter:in
261 Beiträge seit 2015
vor einem Jahr
Publishen von statischen Files in Unterprojekten funktioniert nicht

Hallo zusammen,

folgendes Szenario:

Projekt A (Console App) hat eine Abhängigkeit auf Projekt B (ASP.NET Core Web API).
Projekt B hat einen wwwroot Ordner mit einer einzelnen index.html. Diese Datei soll mit in das Ausgabeverzeichnis kopiert werden.

Mit dem folgenden Problem:

Ohne Publish funktioniert es korrekt: Der wwwroot Ordner wird inklusive Inhalt in das Ausgabeverzeichnis kopiert.
Sobald ich versuche das Projekt A zu publishen, erhalte ich im Ausgabeverzeichnis bzw. Publishverzeichnis den wwwroot Ordner nicht.

Aus dem Bauch heraus hätte ich jetzt erwartet, dass er hier auch den wwwroot Ordner von Projekt B publishen sollte.
Im Anhang findet ihr ein Beispielprojekt. Kann mit folgenden Befehl getestet werden:

dotnet publish -c Release

PS: Wenn ich das Projekt B selbst publishe, dann funktioniert es.

16.807 Beiträge seit 2008
vor einem Jahr

Prinzipiell ist es nicht wirklich vorgesehen, dass eine Konsolenapplikation(!) eine Abhängigkeit auf ein Web-Projekt hat und dort dann die statischen Elemente mitkommen.
Das widerspricht eigentlich so ziemlich dem gesamten Deployment-Weg - und zwar Allgemein. Der Deploymentmechanismus wird niemals vererbt.
Davon abgesehen werden Web Applikationen i.d.R. über spezifische Pakete deployed, was in Konsolenanwendungen unbekannt ist. Das ist also ein von Grund aus anderer Mechanismus.

Welches Szenario ist das denn, dass sowas gewünscht ist? Vielleicht kann man dann einen Tipp für einen besseren Weg oder dann eben Workaround geben.

Wenn ich das Projekt B selbst publishe, dann funktioniert es.

Das ist klar, weil Du in diesem Fall einen Flow startest, der das Publishen von Webprojekten dient.
Das ist aber bei einer Konsolenanwendung anders.

D
dannoe Themenstarter:in
261 Beiträge seit 2015
vor einem Jahr

Es handelt sich bei dem Projekt A um eine Serveranwendung die früher als WinForms-Anwendung umgesetzt wurde. Die Möglichkeit zur Konfiguration bzw. Überwachung der Anwendung wurde damals direkt im gleichen Projekt mit WinForms umgesetzt. Die Serveranwendung stellt einen TCP Server zur Verfügung mit dem sich Clients verbinden können. (Heute würden wir das als HTTP-Schnittstelle umsetzen.)

Irgendwann kam die Anforderung dass die Anwendung als Windows Dienst laufen soll. Es wurden also alle WinForms-Referenzen entfernt und eine Konsolenanwendung daraus.
Die Möglichkeit zur Konfiguration und Überwachung flog raus. Später kam diese Anforderung dann aber wieder: Es wurde eine Web API entwickelt und Projekt B ist entstanden. Die Web API wird dann von einer kleinen SPA angesprochen, die selbst von dem Projekt B gehostet wird. (Die SPA ist meine statische index.html Datei)

Projekt A soll bei Bedarf aber auch ohne Projekt B lauffähig sein. Projekt B wird auch niemals im IIS oder als Azure Web App Service gehostet, sondern immer in einer Konsolenanwendung.

16.807 Beiträge seit 2008
vor einem Jahr

Dann nimm Dir 2h Zeit und zieh es gerade.

Edit: ums zu präzisieren.
Im Endeffekt funktioniert .NET nicht so, wie Du Dir das vorgestellt hattest.
In .NET ist nicht die Runtime für das Deployment verantwortlich, sondern das zu deployende Projekt. Wenn Du Projekt B zu Projekt A verweist, dann ist das nur ein Verweis der Assembly, aber nicht des Projekttyps - und damit ist der Deploymentflow für Projekt A auch vollkommen unbekannt.
Du bekommst daher aus Projekt B nur das, was zum Build definiert ist, aber nicht das Deployment.

Eine ASP.NET Core Anwendung ist zur Laufzeit ebenfalls eine Konsolenanwendung, völlig egal wo sie gehostet wird. Aber das Projekt ist kein Konsolenprojekt, sondern ein Webprojekt.
Und das Deployment eines Konsolenprojekt hat einen anderen Mechanismus als ein Webprojekt. Willst Du ein Konsolenprojekt deployen, das dann wiederum das Deployment eines Webprojekts startet; dann musst Du Dir das selbst zusammen bauen, zB als externe Referenzen (Content Files mit statischem Pfad).

Standardmäßig gibt es im gesamten .NET Kosmos (und gabs auch nie) eine Deployment-Hierarchie von abhängigen Projekten.
Im .NET Ökosystem ist vorgesehen, dass jede Applikation für sich ein Deploymentmechanismus hat; was in anderen Technologien auch der Fall ist.

Womöglich wäre es daher, wie oben gemeint, besser, wenn Du insgesamt Deine Solution gerade ziehst.
Gerade wenn man Anforderungen hat, die sich ändern, sollte man das auch bei Deployments beachten.