Laden...

Wie kann ich Bibliotheken sinnvoll Verwalten?

Erstellt von panicJonny vor 4 Jahren Letzter Beitrag vor 4 Jahren 1.910 Views
P
panicJonny Themenstarter:in
64 Beiträge seit 2011
vor 4 Jahren
Wie kann ich Bibliotheken sinnvoll Verwalten?

Hallo zusammen,

bei meiner Arbeit, fallen viele kleinere Projekte an, die in Teilen gemeinsamen Code haben. Da hat sich im Laufe der Zeit einiges angesammelt.

hier mal eine logging Klasse, da mal ein paar Klassen zum ansteuern von managed Switches u.s.w

Das ist mittlerweile eine schöne Ansammlung von code geworden. Nur langsam wirds ein wenig unübersichtlich. Ich weiß nicht mehr wo was in welcher Version aktuell ist.

Ich habe da ein paar Sachen ausprobiert:

-> bauen von Nuget Packages: da finde ich den Workflow ziemlich doof bei bugfixes und Erweiterungen. Packages automatisch erstellen lassen geht ja nur bei .Net Core anwendungen und das erzeugt bei mir immer einen Wust an dlls. Von Hand ist das ziemlich mühsam. nuspec Datei ändern, binary umkopieren, nuget package erzeugen und dann ins Repository Verzeichnis kopieren und dann im Zielprojekt updaten.

Vorteil ist, dass Unittests in einem eigenem Projekt leichter möglich sind (wenn machbar)

-> als SVN external einbinden: Eigentlich eine ziemlich runde Sache. Nur leider kann man gemeinsame Abhängigkeiten nicht gut auflösen. Man hat dann am Ende im Zielprojekt teilweise zig mal die gleichen Klassen

-> Sourcen kopieren: So mache ich das gerade. Nur leider verschwindet der Überblick, was denn jetzt die letze Version mit den letzten Bugfixes und den neuesten Features ist.

Wie macht ihr das. Hat da wer einen Tip für mich?
Zu bedenken ist, dass ich nicht der einzige bin, der diese Klassen benutzt, aber der einzige, der dran rumschraubt.

Grüße,

16.807 Beiträge seit 2008
vor 4 Jahren

Dafür gibts Git, NuGet und SemVer.
Standardwerkzeuge jedes .NET Entwicklers 😃

Wenn Du das Handling von NuGet doof findest, dann scheint Dein Prozess hier einfach Käse zu sein.
Wie ist denn der Ablauf? Normalerweise muss man hier nichts, absolut nichts von Hand machen. Das kann alles der DevOps bzw. der CI/CD Prozess automatisieren - sollte er sogar.

Ein Beispiel, wie sich das in Sekunden dank TFS/VSTS automatisieren lässt, findest Du hier: AzureDevOps-YamlBuildSamples - Nuget
Das nimmt alles ab, was es in Sachen NuGet Erzeugung gibt:

  • Bauen
  • Testen
  • Versionieren (sowohl stable wie auch unstable anhand des GitHubFlows)
  • Paketieren
  • Publishen
P
panicJonny Themenstarter:in
64 Beiträge seit 2011
vor 4 Jahren

Wie mein Workflow mit Nuget ist, hab ich ja hin geschrieben.

Git ist nicht und TFS auch nicht.

16.807 Beiträge seit 2008
vor 4 Jahren

Haste eben nicht wirklich. Sonst hätte ich nicht gefragt.
Aber wenn Du so wortkarge Antworten bevorzugst, dann mach ich das ma genauso.

Insgesamt hört sich das bei Dir an, dass die Grundorganisation schon alles andere als so ist, wie sie sein sollte.

da finde ich den Workflow ziemlich doof bei bugfixes und Erweiterungen.

Es gibt nicht "den Workflow".

Der aktuell aber am meisten verwendete und empfohlene, sei es im professionellen oder OSS Umfeld; der ist GitHubFlow.
Davon scheinst aber weit weg zu sein.

Packages automatisch erstellen lassen geht ja nur bei .Net Core anwendungen

Nö.

und das erzeugt bei mir immer einen Wust an dlls.

dann ist die Software Architektur Käse.

Von Hand ist das ziemlich mühsam. nuspec Datei ändern, binary umkopieren, nuget package erzeugen und dann ins Repository Verzeichnis kopieren und dann im Zielprojekt updaten.

man muss nichts per Hand ändern - noch nie.
Egal ob .NET Framework, .NET Core oder .NET Standard.

als SVN external einbinden:

bad practise genauso wie git submodule

Sourcen kopieren:

totale Käse, von Vorn bis hinten.

P
panicJonny Themenstarter:in
64 Beiträge seit 2011
vor 4 Jahren

Nö.

Gut, ich spezifiziere es mal genauer. vom VS Studio das NuGet Package erstellen lassen geht nur bei .Net Core Anwendungen. Falls ich falsch liege, dann bitte her mit der Anleitung, ich finde nämlich nichts.

dann ist die Software Architektur Käse.

Ich gebe ja gerne zu, dass ich was falsch mache. Kompiliere ich meine Biblioteken als .Net Core, kommen alle benutzen Referenzen von .Net Core mit ins Ausgabeverzeichnis.

man muss nichts per Hand ändern - noch nie.
Egal ob .NET Framework, .NET Core oder .NET Standard.

Die Version wird im .nuspec beim compilieren automatisch angepasst? Bei mir leider nicht.

totale Käse, von Vorn bis hinten.

Meine Rede

Ich bin leider an SVN und VS ohne TFS gebunden und das lässt sich auch nicht ändern.

16.807 Beiträge seit 2008
vor 4 Jahren

Falls ich falsch liege, dann bitte her mit der rAnleitung, ich finde nämlich nichts.

Offizielle Doku - "Erste Schritte": Quickstart: Create and publish a package using Visual Studio (.NET Framework, Windows)

In Kombination mit GitVersion kann man sich anhand der Git Historie automatisch die Version im SemVer-Stil berechnen lassen.
Ob es dazu ein SVN Äquivalent gibt; das weiß ich nicht.
Spätestens basierend auf Year-Month-Day kann man sich aber die Version automatisieren.

Jeder Schritt, der mit NuGet in Zusammenhang steht, ist voll automatisierbar.
Du machst Dir an der Stelle durch manuelle Schritte selbst das Leben schwer (und fehleranfällig).

Kompiliere ich meine Biblioteken als .Net Core, kommen alle benutzen Referenzen von .Net Core mit ins Ausgabeverzeichnis.

Das ist auch im Falle von .NET Framework oder .NET Standard der Fall. Wenn nicht, dann weiß ich entweder nicht, was Du meinst - oder hast nen Config-Fehler.

Die Version wird im .nuspec automatisch angepasst? Bei mir leider nicht.

Siehe Punkt 1; zeigt auch der Link.

C
26 Beiträge seit 2016
vor 4 Jahren

Hi panicJonny,

an NuGet führt mMn kein Weg vorbei.

Ich vermeide klassische .NET Framework-Projekte, denn die benötigen (wie Du geschrieben hast) manuelle Zuarbeit.
Meine Bibliotheken sind nur noch .NET-Standard-Projekte, bei denen ich das Target-Framework in der Projektdatei anpasse, um Legacy-DLL's und gleichzeitig .NET-Core DLL's zu erzeugen.
Das sieht ungefähr so aus:


<TargetFrameworks>net46;netstandard2.0</TargetFrameworks>

Damit bekommst Du das Packaging-Feature von Visual Studio geschenkt 😃

Bei reinen Legacy-Projekten, habe ich leider auch noch keinen anderen Weg gefunden, als die .nuspec-Datei selber zu erzeugen und dann über nuget.exe das Paket bei Bedarf zu erstellen:


nuget.exe pack -IncludeReferencedProjects -properties Configuration=Release

Ein Repository-Verzeichnis würde ich nicht verwenden.
Ich benutze einen Nexus-Server, der ist kostenlos und einfach zu installieren:
https://de.sonatype.com/nexus-repository-sonatype

Das Ganze könnte man/frau automatisieren (z.B. per nuget push) und auch die Versionierung ist wohl automatisch machbar:
https://stackoverflow.com/questions/23754398/how-do-i-auto-increment-the-package-version-number

Da kann man sich mit Batch-Dateien, PowerShell usw. austoben, aber ich würde das ehrlich gesagt nicht machen. Der Weg über .NET-Standard-Projekte zu gehen ist leichter und zeitgemäßer.

Bezüglich SVN kann ich Dir nur den Tip geben: Wechsel zu Git.
Es ist wirklich ein Quantensprung bezüglich der Versionierung und der Teamarbeit.
Ein eigener GitLab-Server auf ner kleinen Ubuntu-Kiste ist schnell aufgesetzt oder Du verwendest eine AWS-Maschine:
https://aws.amazon.com/marketplace/pp/B071RFCJZK

P
panicJonny Themenstarter:in
64 Beiträge seit 2011
vor 4 Jahren

@Abt

Der Link hat schon mal ziemlich weiter geholfen. Ich sag nur Filterblase. Ich hab imm er nur Anleitungen gefunden, wie man den Käse halb Hand erstellt. Ich wusste zum Beispiel gar nicht, dass ich nuget spec auch auf das Projektfile loslassen kann. Ich hab das immer auf die dll selber gemacht.

Bei deinem Link muss ich nur das nuspec einmal von Hand erzeugen und den Rest kann ich mit ein wenig Post-Build events machen. Auf jeden Fall eine deutliche Erleichterung zum bisherigen Vorgehen.

@codesoldier

Wenn ich anfange einen eigenen GitLab Server in einer VM aufzusetzen bekomme ich tüchtig Haue von unserer IT (und das Zurecht). Manche Sachen muss man einfach nehmen, wie sie sind.

16.807 Beiträge seit 2008
vor 4 Jahren

Wenn ich anfange einen eigenen GitLab Server in einer VM aufzusetzen bekomme ich tüchtig Haue von unserer IT (und das Zurecht). Manche Sachen muss man einfach nehmen, wie sie sind.

Zu unrecht.
Die IT sollte haue bekommen, dass sie als Dienstleister nicht in der Lage ist die Plattform für die notwendigen Arbeitsprozesse zu stellen.
Ein großes Problem in Deutschland - und eines der Grunde, wieso es so viel Schatten-IT gibt. Seh ich als Berater leider immer wieder und scheue mich nicht davor den Verantwortlichen die Augen zu öffnen.
Eine IT, die ihren Dienstleistungspflichten nicht nachkommt, ist ein Unternehmensrisiko - sowohl aktiv wie auch passiv.