Deployment-Strategie mit geteilten Abhängigkeiten?

BAGZZlash

Moderator
Teammitglied
Ich entwickle kleine Tools in C#. Jedes davon hat nur eine spezifische Aufgabe ("Microservice"), daher gibt es viele davon. Jedes einzelne hängt von einer Reihe von NuGet-Packages ab (aber alle Tools jeweils von den gleichen Packages). Die Weitergabe an die User soll möglichst einfach erfolgen und kein großes Herumgeturne mit irgendwelchen Installern oder so erfordern.

Daher verwende ich ein "single file deployment", bei dem pro Tool alle Dependencies in die entstehende Binary gelinkt werden (zumindest denke ich, dass es das ist, was passiert). Damit habe ich im Ergebnis eine .exe-Datei pro Tool, die alles enthält. Das ist eigentlich super, denn so erreiche ich meine Mobilität. Problem ist nur, dass durch die enthaltenen Abhängigkeiten jedes einzelne Tool groß wird, über 50 MB. Ohne gelinkte Abhängigkeiten sind's nur etwa 170 kB, was viel besser zum reduzierten Aufgabenbereich der kleinen Tools passt.

Da alle Tools von denselben Dependencies abhängen, ist es außerdem unnötig redundant, immer alles reinzulinken. Ich hätte gern einen Ordner, in dem einmal die Abhängigkeiten hinterlegt werden, und wo dann die einzelnen Tools in jeweiligen Ordnern "daneben" liegen können und nur jeweils ihre 170 kB groß sind. Die Tools würden sich ihre Abhängigkeiten dann teilen. Geht sowas? Ich verwende Visual Studio 2019.
 

german

Aktives Mitglied
devCommunity-Experte
Ich weiß dass man mehrere Projekte in eine Solution packen kann.
Hab sogar ein Plugin gefunden, was dir dabei hilft:
Und ich bin mir ziemlich sicher dass eines der Benefits davon ist, dass man gemeinsame Abhängigkeiten für die Solution definieren kann.
Ich hab das aber selbst noch nie ausprobiert und ich weiß nicht ob es verhindert dass die Abhängigkeiten statisch gelinkt werden. Das ist sicher noch mal eine Frage der Einstellungen der einzelnen Projekte.
 

Lowl3v3l

Aktives Mitglied
devCommunity-Experte
Ich denke eine andere Lösung, als die von @german, die vmtl. die kanonische ist, wäre vielleicht, es anzustellen wie bei busybox?
Ich kenne nun dein genaues Problem nicht, aber das ist am Ende vielleicht die platzsparendste Lösung, besonders, wenn du die Tools eh immer alle gleichzeitig irgendwo installieren willst.

MfG
 

BAGZZlash

Moderator
Teammitglied
Problem ist halt, dass später idealerweise andere Entwickler (wenn auch zunächst nur aus unserem "Dunstkreis") auch solche Tools schreiben können sollen. Gemeinsame Solution wäre hier vermutlich zu sperrig. Wir denken daran, dass wir ein GitHub-Repo mit einer Blaupause für die Tool-Entwicklung zur Verfügung stellen (dieses enthält die Packages und etwas Rumpfcode für die Kommunikation mit der "Orchestrator"-App). Sollte dort ein Entwickler entscheiden, ein zusätzliches Package zu benötigen, müsste sein Deployment dieses entsprechend mitbringen, dennoch aber die Möglichkeit haben, den bestehenden Bestand an Dependencies nutzen zu können, ohne das ebenfalls mitbringen zu müssen. Hm, die eierlegende Wollmilchsau mal wieder. @Lowl3v3l, mit Busybox meinst Du das hier?
 

Lowl3v3l

Aktives Mitglied
devCommunity-Experte
Jup genau, dieses Projekt meine ich. Ich würde da halt eiskalt so denken: Das irgendwie aufsplitten macht Arbeit und Entwicklungsoverhead und vmtl. auch Probleme bei der Maintenance. Diese Lösung braucht, angenommen irgendwann braucht mal jemand nur einen Teil der Tools, mehr Festplattenspeicher als strikt nötig, ja. Aber so wie das klingt sind diese Tools so klein, dass wenn DAS wirklich ein Problem ist, .Net vmtl. eh die falsche Plattform für die Entwicklung wäre. Also ist meine Maxime: gibt jedem alles, 10 oder 20 MB mehr sollten heutzutage wohl kaum noch stören.

MfG
 

BAGZZlash

Moderator
Teammitglied
Okay, das stimmt natürlich. Klar, wenn's blöd läuft, ist der Tools-Ordner irgendwann ein GB groß oder zwei. Aber eigentlich ist das ja egal.
 
Oben Unten