Bibliotheken für viele Projekte bereitstellen, aber wie ?!

Hallo zusammen,

ich habe schon vor einige Zeit ein relativ umfangreiche Bibliothek geschrieben, die aus mehreren voneinander abhängigen DLLs besteht. Nun gibt es dazu auch noch einige Programme, die diese DLLs verwende, wobei nicht immer alle Projekte alle DLLs verwenden müssen.

Für alle Projekte habe ich eine Continous Integration Umgebung aufgesetzt und jedes Projekt kompiliert dort auch einzeln. Die Basis-Bibliotheken werden dabei als Projekte in die jeweilige Solution eingebunden.

Ich würde jetzt gerne alles so strukturieren, daß ich in der Lage bin, bei Änderungen in einer der Basis-Bibliotheken, automatisch alle Projekte mit der neuen Version durchkompilieren zu lassen. Daß würde aber wohl erfordern, daß ich in den Projektsolutions nicht die Bibliotheksprojekte einbinde, sondern nur noch die DLLs.

Dann verliere ich leider die Möglichkeit zu debuggen und ggf. Änderungen direkt in den Bibliotheken machen zu können.

Hat da jemand einen Vorschlag, wie ich das erreichen kann: Debugging, dirkete Änderungen und doch Compile aller Projekte mit dem letzten Stand der DLLs?

Ich schrecke auch nicht vor Build Skripten zurück ... 😉 mir fehlt nur der Ansatzpunkt und ich hätte gerne mal gehört, wie andere Leute dieses Problem angegangen sind.

Vielen Dank im Voraus.

BaNDiT

Daß würde aber wohl erfordern, daß ich in den Projektsolutions nicht die Bibliotheksprojekte einbinde, sondern nur noch die DLLs.

Nein warum?
Du kannst doch in allen Solutions auf die selben DLL-Projekte verweisen. Wenn du eine Solution compilierst, verwendet sie das aktuelle Projekt der DLLs.
Wenn du willst kannst du dir eine Solution erstellen in der alle Projekte drin sind. Wenn du die compilierst, rödelt es sämtliche Projekte durch.

Ich weiß ja nicht ob ich dich richtig verstehe, aber wenn sich eine DLL ändert muss man NICHT das Projekt neu compilieren das die DLL verwendet. Genau das ist Sinn von DLLs.

PS: Das natürlich nur falls du wirklich willst dass eine geänderte DLL in evtl. vielen Projekten automatisch drin ist, wenn du die compilierst. Wär auch nachvollziehbar wenn du selber kontrollieren willst welches Projekt wann eine neue DLL bekommt.

Bibliotheken, die ich in mehreren Anwendungen nutze, liegen bei mir alle in NuGet.
Im öffentlichen Repository wenn ich sie der Welt zur Verfügung stellen will; interne Bibliotheken auf einem eigenen, privaten NuGet Share auf meinem Server.

Auf refenzierte DLLs im Release-Modus kann aber natürlich nicht mehr per Debug zugegriffen werden. Wobei ich mich dann frag wie gut die DLL getestet ist, wenn man noch rein-debuggen muss.
Man kann aber in NuGet Debug-Files (Dll + Symbols) extra ausliefern bzw. über ein SymbolPackage mitliefern.

Hallo,

danke für die ersten Antworten.

Ok es ist mir klar, daß man die DLLs einfach so austauschen kann, das würde ich ja auch gerne tun.

NuGet war einmal ein Ansatz, den wir verfolgt haben. Allerdings sind wir daran gescheitert, daß wir immer wieder Dinge im Datenbankmodell nachpflegen mußten und dann eben alle Projekte mit der aktuellen Version versorgen mußten. Daß hat dazu geführt, daß man ständig an den Paketen herumgewerkelt hat. Durch die fehlende Debugging Funktionalität wurden die Fehler schwer auffindbar und das Ändern war recht aufwendig, daß man immer erst das Package durch den Buildserver schieben mußte, bevor man weiterarbeiten konnte. Das war eben noch nicht optimal.

Aber vielleicht könnte man das nochmal angehen.

Gibt es noch mehr Ideen?

LG,

BaNDiT

Ich glaub Du willst zwei Ziele verfolgen, die in unterschiedliche Richtungen gehen.
Source-Debugging und DLL-Austausch geht nicht im Einklang. Dann müsst ihr eben alle immer das gesamte Projekt teilen statt die DLL.

Dass man für NuGet eben bauen muss: das ist bei jeder geteilten DLL so. Also kein Nachteil. Zudem kann man das Package ja sehr einfach automatisch generieren und der Update-Prozess ist doch ein Klacks mit den neuen VS.....

Hi,

das stimmt. Mit Teamcity sollte auch das automatische Update und damit die kontinuierliche Integration von neuen Versionen eines Packages kein Problem sein. Ich meine man könnte in den NuGet Packages auch die Debug-Infos mitgeben (also die PDB-Dateien) ...

Dann müssen wir in Zukunft noch modularer denken, damit sich nicht gleich immer alles ändert, wenn man mal eine Funktion korrigiert.

LG,

BaNDiT

Hallo,

falls es noch aktuell sein sollte:
Man kann zentrale Bibliotheken, also selbstgeschriebene, in beliebig viele Projekte einbinden, muß dann aber die Quellfiles über Projekt | Hinzufügen... einbinden und
beim Bestätigen den geteilten OK-Knopf des Filedialogs beachten.
"Als Link einbinden" ist hier die erste Wahl, macht die Bibliothek debugbar und verhindert Versionswirrwarr.
(Visual Studio 2010)