Laden...

Verteilungsmöglichkeiten von Komponenten

Erstellt von mfe vor 7 Jahren Letzter Beitrag vor 7 Jahren 1.896 Views
M
mfe Themenstarter:in
177 Beiträge seit 2009
vor 7 Jahren
Verteilungsmöglichkeiten von Komponenten

Hi,

mir ist leider kein treffender Titel eingefallen, vlt. kann das jemand noch präzisieren.

Unter Komponenten verstehe ich eine Art Modul in einem Projekt, das Projektübergreifend eingesetzt werden soll. Man könnte ebenso von einem firmeninternen Framework sprechen.

Bei uns sind das zum Großenteil noch klassische .NET Framwork Class Libraries.

Entweder werden die kompilierten Assemblies direkt in die Solution "verlinkt" und dann wird auf diese Referenziert, oOder das ganze Class Library Projekt wird in die Solution gehängt. Das kann zum Teil echt grausig werden, wenn das Projekt aus einem fremden TFS Repository kommt.

Was für Best practice Möglichkeiten gibt es, um ein internes Firmen Framework zu etablieren? Man sollte es möglichst einfach in bestehende Projekte einbinden und auch erweitern können.

Auf die Schnelle fällt mir lediglich das Hosten eines Nuget Servers ein.
Vorteil:*Entwickler können die Module ganz einfach aus dem VS installieren *Entwickler können die installierten Module nicht "kaputt machen"

Nachteil:*NugetServer einrichten wahrscheinlich aufwendig *Die Visual Studio Projekte die Verteilt werden sollen, müssten angepasst werden (quasi ein Build Config muss erstellt werden->diese konvertiert die erstellte Assembly in ein NugetPackage und lädt sie zum Firmen eigenen NugetServer hoch

Evtl. wäre es auch möglich, über ein Script das TFS Repository herunterzuladen, zu builden und darüber das NugetPackage zu erstellen und hochzuladen.

Hat jemand sowas im Einsatz und kann Erfahrungswerte teilen? Gibt es noch andere Möglichkeiten ein Framework Projektübergreifend ein zu setzen?

Ich denke der Aufwand lohnt sich allemal.

16.842 Beiträge seit 2008
vor 7 Jahren

Um NuGet werdet ihr vertretbar kaum drum herum kommen. Darauf basiert mittlerweile das gesamte Tooling und auch die neue .NET CLI Welt.

Du hast mehrere Möglichkeiten, die ich zB selbst bzw wir auch so nutzen.

  • Offene Bibliotheken stable auf NuGet.org - Continuous Delivery via AppVeyor
  • Offene Bibliotheken beta auf MyGet als Public Channel - Continuous Delivery via AppVeyor
  • Interne Bibliotheken via TFS Build und TFS NuGet Server (gibts nen eigenen Build Task dafür)
  • .. oder interne Bibliotheken auf MyGet als Private Channel (kostet)
    via NuGet.exe.config kannst Du NuGet Server pro Projekt definieren, sodass Beta und Stable Packages von verschiedenen Quellen abgerufen werden.

Einrichten via AppVeyor und NuGet und MyGet dauert ca. 5 Minuten, wenn man ein mal eine YML entwickelt halt, die das abdeckt.
Mein Flow ist:

  • commit auf develop startet ein Build mit Continous Deployment als Beta NuGet Package auf MyGet.org
  • commit auf masterstartet ein Build mit Continous Integration mit Test Only
  • commit auf master mit release Tag (GitHub Release) löst Continous Deployment als Beta NuGet Package auf NuGet.org aus
    So wird zB. auch mein QuickIO gebaut und verwenden wir in der Company auch so (hab ich eingeführt) bei Open Source Projekten.

Task auf TFS mit entsprechendem CI circa 10 Minuten.

Direktes Linken auf DLLs oder gar Projekte: absolut nicht mehr stand der Technik.
Viel zu viele Nachteile - vor allem in Teams.

D
985 Beiträge seit 2014
vor 7 Jahren

Seit der Version x.y von NuGet kann man auch einfache Verzeichnisse als Repository verwenden. Einrichtungszeit 10 Sekunden.

Damit kann man ja erst mal starten und bei Bedarf auf einen echten Server wechseln.

T
62 Beiträge seit 2012
vor 7 Jahren

Unter Scott Hanselmann - Creating a NuGet Package in 7 easy steps - Plus using NuGet to integrate ASP.NET MVC 3 into existing Web Forms applications gibt es ca. ab der Hälfte des Posts (Ab "How I made my own NuGet package and you should too") eine Anleitung wie man mit der NuGet.exe ein nuget Paket bauen kann.

W
955 Beiträge seit 2010
vor 7 Jahren

@tASven: Bearbeite deinen Link nochmal, da ist ein HTML-Break drin.

2.207 Beiträge seit 2011
vor 7 Jahren

@witte: Link im Beitrag stimmt, das Problem ist das Forum. Ich korrigier es gleich.

M
mfe Themenstarter:in
177 Beiträge seit 2009
vor 7 Jahren

Hi,

danke für Rückmeldungen. Wir haben die verschiedenen Varianten besprochen werden aber wahrscheinlich das Ganze über Visual Team Service erledigen.

https://marketplace.visualstudio.com/items?itemName=ms.feed

lg

BZW. was spricht eigentlich gegen Nuget Packages die auf einem Share liegen? Hat jemand damit Erfahrung? Kann es da bei NugetPackage Abhänigkeiten zu Problemen kommen?