NuGet ist eine praktische Paketverwaltung f\u00fcr die .NET Welt: Andere Entwickler k\u00f6nnen dort Bibliotheken zur Verf\u00fcgung stellen, damit sie jeder Entwickler verwenden kann. Im besten Falle sind diese zudem quelloffen, sodass jeder mitwirken kann – statt das Rad st\u00e4ndig neu zu erfinden. Verwendet man f\u00fcr den eigenen Quellcode, in dem man die NuGet-Pakete verwendet, eine Versionsverwaltung, sollte man jedoch darauf achten, die NuGet-Ordner dort korrekt auszuschlie\u00dfen.<\/p>\n
Der Paketmanager erstellt pro Projektmappe einen Zwischenspeicher der heruntergeladenen Pakete im Ordner packages<\/strong>. Damit entf\u00e4llt das mehrfache herunterladen eines Paketes, weil man dies in mehreren Projekten einer Projektmappe verwendet. In diesem Ordner befinden sich die Bibliotheken (meist .dll Dateien) mit ggf. notwendigen Abh\u00e4ngigkeiten.<\/p>\n Doch Zusammen mit der Quellcode-Verwaltung Git ergibt sich damit ein Problem: Der packages-Ordner wird standardm\u00e4\u00dfig ebenfalls versioniert. Das kann nicht nur die \u00dcbersicht st\u00f6ren, sondern bl\u00e4ht das Repository auf: Das Klonen wird langsamer und es verschwendet zudem Speicher. Mit ein paar Paketen und ihren Abh\u00e4ngigkeiten w\u00e4chst er n\u00e4mlich schnell auf dutzende MB an.<\/p>\n Generell ist es keine gute Idee, Bin\u00e4rdateien zu Versionieren. Git kann dort keine Unterschiede erkennen und sie inkrementell speichern, was bei textbasierten Dateien sehr effizient funktioniert. Anders ausgedr\u00fcckt: Ihr habt dort eine 500 KB gro\u00dfe DLL-Datei. Wird diese aktualisiert, belegt sie im Repository noch mal 500 MB (also insgesamt 1 MB) – selbst wenn nur Kleinigkeiten ge\u00e4ndert wurden. Das mag bei 500 KB noch wenig erscheinen. Es summiert sich aber, zumal der Speicherbedarf durch Updates mit der Zeit w\u00e4chst.<\/p>\n Mit Paketmanagern wie NuGet besteht zudem keine Notwendigkeit daf\u00fcr: Sie dokumentieren in der csproj-Datei des Projektes, welches Paket in welcher Version ben\u00f6tigt wird. Dadurch kann man sich diese bei Bedarf aus dem Netz laden.<\/p>\n Es empfiehlt sich daher, mithilfe der versteckten Datei\u00a0.gitignore<\/strong> den Ordner auszuschlie\u00dfen. Dazu \u00f6ffnet man besagte Datei mit einem Texteditor und f\u00fcgt die beiden folgenden Zeilen ein:<\/p>\n Git wird den Inhalt des Ordners nun ignorieren, lediglich die Konfigurationsdatei der Repositories ist davon ausgenommen. Dort sind ggf. manuell hinzugef\u00fcgte eigene Paketquellen aufgelistet. \u00c4hnlich wie bei der csproj handelt es sich um eine reine Konfigurationsdatei, die man problemlos versionieren kann und sollte.<\/p>\n Wichtig ist zu verstehen, dass die .gitignore<\/strong> nur f\u00fcr neue\/ver\u00e4nderte Dateien gilt. Sie hat keine Auswirkungen auf bereits eingecheckte Inhalte bestehender Commits – diese bleiben bestehen, selbst wenn man nachtr\u00e4glich eine Datei ausschlie\u00dft. Am wenigsten Arbeit und Probleme macht man sich, in dem die .gitignore<\/strong> zu Beginn eines Projektes als Erstes anlegt. Vor dem ersten Commit sorgsam pr\u00fcfen, was f\u00fcr Dateien eingecheckt werden und ggf. entsprechende Ausnahmen festlegen. Die gibt es in nahezu jedem Projekt. In .NET werden z.B. Bin\u00e4rdateien in bin angelegt. Dort macht es ebenfalls wenig Sinn, nach jedem Build neue Bin\u00e4rdateien zu haben, die Git als neue \u00c4nderungen erfasst.<\/p>\n Wenn ihr den packages Ordner bereits zuvor eingecheckt habt, k\u00f6nnt ihr diesen mit git rm<\/strong> wieder entfernen:<\/p>\n Dies bezieht sich nur auf Git und entfernt nichts in eurem Arbeitsverzeichnis. Die Pakete bleiben weiterhin dort, wo sie f\u00fcr die Entwicklung ja auch gebraucht werden. Allerdings hat auch das keine Auswirkungen auf den Verlauf (History) eures Repositorys. Mit anderen Worten: In fr\u00fcheren Commits ist der Ordner weiterhin vorhanden und belegt damit beim Klonen weiterhin Speicher.<\/p>\n Das kann theoretisch gel\u00f6st werden, in dem man den Verlauf neu schreibt: Vereinfacht gesagt entfernt das den Ordner aus dem Commit, in dem er erstmalig hinzugef\u00fcgt wurde. Au\u00dferdem in allen weiteren Commits, die z.B. durch Updates oder die Installation neuer Pakete in diesem Ordner entstanden sind. Dies ist – wenn \u00fcberhaupt – mit \u00e4u\u00dferster Vorsicht zu genie\u00dfen: Git ist nicht daf\u00fcr gedacht, Commits bauen aufeinander auf. Zwar bietet Git M\u00f6glichkeiten um dies umzusetzen. Allerdings werden alle Kopien dadurch unbrauchbar bzw. es kann zu Problemen f\u00fchren, da die ja dann einen anderen Versionsstand besitzen.<\/p>\n Praktikabel ist das aus meiner Sicht nur, wenn ihr alleine an dem Repository arbeitet. Im Falle von mehreren Personen m\u00fcsst ihr sicherstellen, dass dies zu einem festgelegten Zeitpunkt stattfindet, alle informiert sind, ihre lokalen Kopien l\u00f6schen und neu klonen. Zu empfehlen ist es nicht. Gerade bei kleineren Datenmengen ist der bessere Weg, diesen Fehler mit der .gitignore<\/strong> nachtr\u00e4glich zu korrigieren und den Datenm\u00fcll<\/em> im Verlauf stehen zu lassen. Beim n\u00e4chsten Repository wei\u00df man es dann besser, sodass dieses Problem von Anfang an vermieden werden kann. <\/p>\n","protected":false},"excerpt":{"rendered":" NuGet ist eine praktische Paketverwaltung f\u00fcr die .NET Welt: Andere Entwickler k\u00f6nnen dort Bibliotheken zur Verf\u00fcgung stellen, damit sie jeder Entwickler verwenden kann. Im besten Falle sind diese zudem quelloffen, sodass jeder mitwirken kann – statt das Rad st\u00e4ndig neu zu erfinden. Verwendet man f\u00fcr den eigenen Quellcode, in dem man die NuGet-Pakete verwendet, eine …<\/p>\n","protected":false},"author":5,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-3263","post","type-post","status-publish","format-standard","hentry","category-technik-news"],"_links":{"self":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts\/3263","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/comments?post=3263"}],"version-history":[{"count":3,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts\/3263\/revisions"}],"predecessor-version":[{"id":10885,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts\/3263\/revisions\/10885"}],"wp:attachment":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/media?parent=3263"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/categories?post=3263"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/tags?post=3263"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}So l\u00f6st ihr das Problem<\/h2>\n
\n\/packages\/\n!\/packages\/repositories.config\n<\/pre>\n<\/div>\n
Bereits eingecheckten packages-Ordner entfernen?<\/h2>\n
\ngit rm -r --cached packages\ngit commit -m 'Removed NuGet packages directoy\"'\ngit push origin master\n<\/pre>\n<\/div>\n