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.
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.
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:
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.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
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.
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.
@tASven: Bearbeite deinen Link nochmal, da ist ein HTML-Break drin.
@witte: Link im Beitrag stimmt, das Problem ist das Forum. Ich korrigier es gleich.
Microsoft MVP // Me // Blog // GitHub // @Egghead // All my talks // Speakerdeck
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?