C# Bibliotheken / Versionierung

[Ghost_Rider_R]

Hallo zusammen,

ich hätte da mal eine etwas allgemeinere Frage zum Thema Bibliotheken und deren Versionierung. Ich habe mittlerweile diverse Bibliotheken für alle möglichen Aufgaben erstellt, welche sich hin und wieder weiterentwickeln d.h. neue Features kommen hinzu, Bugs werden beseitigt etc. - Soweit so gut -

Wie sollte man jetzt bei Updates vorgehen, wenn ich z.B. eine Bibliothek UmsatzModulAPI habe, welche Methoden aus der Bibliothek DatenbankAPI aufruft und die Bibliothek DatenbankAPI aktualisiert wird von Version 1.0 auf Version 1.1.

Seither habe ich nach dem Update der DatenbankAPI (1.0 > 1.1) das Projekt UmsatzModulAPI genommen und dort dann auf die neue Bibliotheksversion verwiesen. In Zuge dessen habe ich dann auch die UmsatzModulAPI um eine Version erhöht (3.5 > 3.6).

Neue Projektversionen speichere ich dabei immer lokal in einem neuen Verzeichnis z.B.

M:\Software\Bibliotheken\DatenbankAPI\1.0\...
M:\Software\Bibliotheken\DatenbankAPI\1.1\...
...
M:\Software\Bibliotheken\DatenbankAPI\1.6\...

Usw.

Dies hat für mich dann immer zur Folge, dass ich nach einer Änderung immer alle davon abhängigen Bibliotheken anfassen muss, nur damit im Projektverweis auf die neuere Version referenziert wird, ich denke da gibt es einen besseren Ansatz.

Kann man hier nicht einfach sagen, nehme immer die Neuste? im Regelfall ist dies bei mir immer Abwärtskompatibel.

Und Frage 2.
Wie kann ich einstellen, dass im Projekt UmsatzModulAPI nicht jedes Mal auch die DatenbankAPI ins Bin\Debug Verzeichnis kopiert wird? ich habe da zwar eine Option ,,Lokale Kopie" -> Nein gefunden, jedoch wirkt die scheinbar nicht unter .NET 6:

Kann mir da einer einen Tipp geben?

Vielen Dank und LG Ghost Rider

 

[Abudinka]

du kannst theoretisch deine bibliotheken in nuget packages umwandeln und dann referenzieren - wenn du dann modul auf die neue lib hoch ziehen willst, musst du nur die hauptabhängigkeiten aktualisieren und diese holen sich dann ihre sublibs

zum thema mit in den build ordner kopieren bin ich mir gerade nicht sicher ob man das in c# auch zusammenfassen kann, in anderen sprachen kann man alles in die exe packen. Wenn du aber abhängigkeiten hast, müssen die entweder relativ zur exe vorhanden sein oder meines Wissens über das system bereitgestellt werden.

 

[Ghost_Rider_R]

Hallo @Abudinka, mit NuGet Paketen habe ich seither noch nicht wirklich gearbeitet bzw. ich habe immer nur andere Bibliotheken geladen aber keine selbst hochgeladen. Das wäre für mich aber auch keine wirkliche Option, ich habe meinen Code immer gerne lokal bei mir im Haus 😊.

Das ist korrekt, ich habe die Bibliotheken immer alle im selben Verzeichnis wie die EXE, nur finde ich es einfach nicht so Charmant, wenn jede Bibliothek für sich selbst auch noch eine eingene Kopie der Abhängigkeiten im Bin\Debug-Verzeichnis hat, da ich diese Abhängigkeiten ja in anderen Verzeichnissen abgelegt habe und einfach nur in meiner Main.Exe auf alle Abhängigkeiten referenzieren möchte d.h.

Jedes Bibliotheksprojekt soll nur die eingen Bibliothek enthalten und keine Abhängigkeiten und im Hauptprojekt verweise ich auf alle Abhängigkeiten.

Nur wie schalte ich das ab? sonst müsste ich die immer von Hand löschen und das ist unnötig aufwendig, dafür müsste doch diese Funktion sein? nur Funktioniert Sie unter .NET 6 nicht, ich meine unter .NET Framework hatte es mal funktioniert...

 

[Abudinka]

gibt auch möglichkeiten lokale nugetserver zu betreiben, mache das gerade testweise mit team city
wie gesagt wenn deine bib irgendwelche resourcen braucht müssen die halt auf den zielrechner mitgeliefert werden, wofür es glaube 3 varianten gibt:

• Einfach in den Ordner der Exe mit rein kopieren
• "mit rein Compilieren" - wie gesagt keine ahnung ob das bei c# geht
• über nen installer systemweit installieren und bekannt machen, so das die app drauf zugreifen kann.

Was zu designzeit passiert und von wo die da geladen werden ist relativ egal, selbst wenn du auf nuget.org irgendwelche packet benutzt, müssen die ja auch mit ausgeliefert werden, weswegen die meisten c# programme ein haufen dlls mit liefern.

 

[Ghost_Rider_R]

Zusammenkompilieren, das geht, aber soviel ich weiß nicht mit Bibliotheken, aber ich lasse mich auch gerne eines besseren belehren.

Das die nachher im Ordner der Exe landen ist ja kein Problem, da ich in meiner Exe später darauf referenzieren kann, dann passiert das automatisch nur innerhalb vom Bibliotheken-Projekt hätte gerne nicht zusätzlich auch nicht die DLL liegen, das ist irgendwie doppelt gemoppelt :-)

 

[SirKhan]

Sofern alleine programmiert wird und das große Visual Studio verwendet wird, da tue ich immer alle Projekte in einer Projektmappe/Solution zusammenfassen und anstatt der .dll-Datei das andere Projekt referenzieren. Dann wird das direkt verwendet, wenn ich das Exe-Projekt baue. Immer die neuste Datei.

Was das Zusammenkompilieren angeht, verwende ich Fody bzw. Costura.Fody. Kann man einfach über NuGet installieren. Und über eine Config-XML kann man auch einzelne Assemblies ausklammern, sofern gewünscht.

Ich nutze jedoch noch das alte .NET Framework 4.x. Wie genau das nun mit .NET 6 aussieht, kann ich nicht sagen.

Ansonsten kann man immernoch ein Post-Build-Skript ausführen, welches Dateien löscht ^^
Fürs Debuggen wird VS aber vielleicht die Assemblies benötigen.

 

[Ghost_Rider_R]

Ich habe eben festgestellt, dass unter .NET Framework die Funktion "Lokale Kopie" = False (Siehe Screenshot oben) noch funktioniert, unter .NET 6 aber nicht mehr, ist das ein Bug?

 

[X__]

Hi,
wir habe hier ganz ähnliche Probleme und haben das über getrennte Subversion-Repositories
und die Zusammenführung in VS in einer Solution gelöst:

Abhängigkeit:

Hauptprojekt
   ^-- benötigt "Lib A"
   ^-- benötigt "Lib B"
                   ^-- benötigt "Lib C"

Solution

* Hauptprojekt mit Verweis auf "Lib A", "Lib B"
* Lib A
* Lib B mit Verweis auf "Lib C"
* Lib C

SVN

Hauptrepository
 * Lib A als "external" im Hauptrepository eingebunden
 * Lib B als "external" im Hauptrepository eingebunden
 * Lib C als "external" im Hauptrepository eingebunden

Verzeichnisstruktur (alle Unterprojekte liegen in einem "externals"-Unterordner im Hauptordner

/Hauptprojekt-Ordner/
    Hauptprojekt mit Solution, allen Dateien, Verzeichnissen
/Hauptprojekt-Ordner/externals/Lib A/
                                       Lib A-Projekt mit allen Projektdateien, Dateien, Verzeichnissen
/Hauptprojekt-Ordner/externals/Lib  B/
                                       Lib B-Projekt mit allen Projektdateien, Dateien, Verzeichnissen
/Hauptprojekt-Ordner/externals/Lib C/
                                       Lib C-Projekt mit allen Projektdateien, Dateien, Verzeichnissen

• So liegen alle notwendigen Projekte ein einer Verzeichnisstruktur
• wird aktualisiert, werden auch die Unter-Repositories aktualsiert
• man kann bei Bedarf Versionen der Unter-Repositoiries im Abhängigkeit vom Hauptprojekt auf eine bestimmten Stand einfrieren (z. B. wenn Abwärtskompatibilität durchbrochen wird)
• Man kann Tags von Versionsständen bilden, um eine zu einen Zeitpunkt gültige Versionkombination jederzeit wieder herstellen (inkl. der Versionen der Unterrepositories)
• Änderungen, die in gemeinsam genutzen Unterprojekten getätigt werden, stehen sofort anderen Hauptprojekten zur Verfügung

TortoiseSVN und VisualSVN sind bei dieser Vorgehensweise in Kombination super Unterstützungstools

 

[Ghost_Rider_R]

Kann das eventuell mal jemand bestätigen, ob das Verhalten bei euch auch so auftritt?

Ich habe eben festgestellt, dass unter .NET Framework die Funktion "Lokale Kopie" = False (Siehe Screenshot oben) noch funktioniert, unter .NET 6 aber nicht mehr, ist das ein Bug?

Dieser Schalter funktioniert bis .NET Framework d.h. auf False wird keine lokale Bibliothek der Abhängigkeit erstellt, bei .NET 6 aber scheinbar ohne Funktion.

Ist das dann ein Bug?

 

[SirKhan]

Ich hab .NET 6 nicht installiert, aber mit VS 2019 und .NET 5.0 funktioniert "Copy Local"/"Lokale Kopie" noch, sprich es wird dann nicht die referenzierte Assembly.dll in den Ausgabeordner kopiert, falls "No" eingestellt ist.
Ich werde mal alles updaten.

Ergänzung (16. Dezember 2021)

Mit VS 2022 und .NET 6.0 funktioniert der "Copy Local"-Switch tatsächlich nicht mehr, sprich er scheint (zumindest in dem Fall) ignoriert zu werden.

Prinzipiell sieht es nach einem Bug aus (da die Option ja weiterhin vorhanden ist, aber nicht mehr funktioniert). Dass ohne lokale Kopie der Assembly meine Applikation nicht mehr startet, sollte, wenn explizit per Schalter gewünscht, hier keine Rolle spielen.

Es gibt in VS ja rechts-oben so einen Feedback-Button. Vielleicht bringt es was diesen zu nutzen.

 

[Ghost_Rider_R]

Ok, dann weiß ich hier erstmal Bescheid. Ich nutze den Switch auch nur bei Bibliotheken, bei Anwendungen soll er sich die Bibliotheken dann ja frisch ziehen.

Vielen Dank für eure Hilfe!

Ergänzung (16. Dezember 2021)

Wurde über den Feedback-Button wohl schon gemeldet, jedoch noch nicht behoben. Ich habe gleich mal ein Vote dagelassen, vielleicht bringt es ja was: