Wir haben viele interne Bibliotheken, die wir gerne zwischen Projekten innerhalb des Unternehmens teilen möchten. Dies sind einige der Anforderungen:
- Bibliotheksquellen werden in von Endprojekten getrennten Repositorys gespeichert
- Zu den Endprojekten gehören Bibliotheken über NuGet
- Es muss möglich sein, den Quellcode für eine bestimmte Bibliothek während der Arbeit an einem Endprojekt einfach einzusehen
Das Einrichten unseres privaten NuGet-Repositorys ist kein Problem, das Verwalten von Quellen jedoch. Wir haben versucht, die Quellen über den Quellserver verfügbar zu machen, und das funktioniert, aber nicht ganz: VS lädt die Quellen beim Debuggen von externem Code herunter, aber nicht, wenn Sie versuchen, zur Definition / Implementierung zu navigieren. Grundsätzlich kann man beim Debuggen nur auf den Quellcode zugreifen, was nicht ganz das ist, was wir brauchen.
Die Fragen sind also:
- Welche Möglichkeiten bestehen, um den Zugriff auf den Quellcode interner Bibliotheken zu ermöglichen, ohne dass der Code in demselben Repository / derselben Lösung enthalten sein muss?
- Gibt es eine Möglichkeit, die Kombination Symbolserver / NuGet-Feed so einzurichten, dass VS die Symbole nicht nur zum Debuggen, sondern auch zur Navigation verwendet?
Die Verwendung von ReSharper / anderen Add-Ins ist eine Option.
2
Wir fanden die Verwendung von Nuget für die Verwaltung interner Projekte nicht optimal. Wir haben es schließlich zugunsten von Projekt- und DLL-Referenzen herausgerissen. Ich würde gerne von jemandem hören, der diese Arbeit machen konnte.
—
Robert Harvey
Haben Sie auch einen Symbolserver für die pdb-Dateien eingerichtet, die den in Ihren NuGet-Paketen enthaltenen DLLs entsprechen?
—
RubberDuck
Wir haben genau die gleiche Konfiguration an meinem aktuellen Arbeitsplatz. NuGet-Server (enthält DLLs ohne PDBs) plus Symbolserver (enthält DLLs, PDBs und Quellen). Wir haben auch das gleiche Problem (Quellen und PDBs werden nur beim Debuggen abgerufen). @RobertHarvey: Der NuGet Package Manager ist ein schlechter NuGet-Client. Es unterscheidet nicht zwischen direkten und vorübergehenden Abhängigkeiten und erfordert dumme "Konsolidierungs" -Aktionen. Wir sind auf Paket umgestiegen und haben seitdem nie mehr zurückgeschaut. Es machte das Paketmanagement vernünftig und erträglich und grenzte an angenehm.
—
Allon Guralnek
Ich muss fragen - auch wenn ich dies nicht für unangemessen halte - warum müssen Sie in der Lage sein, in den gemeinsam genutzten / gemeinsamen Paketen nachzuschauen? Zumindest sollte dies theoretisch als Blackbox dokumentiert werden, und die Notwendigkeit, nach innen zu schauen, sollte eher die Ausnahme als die Norm sein. In jedem Fall sind sie in Ihrem Quell-Repository verfügbar, und es sollte daher ziemlich trivial sein, die zu inspizierende Lösung herunterzuladen. Ich kann eine Reihe von Gründen erkennen, warum dies oder Teile davon möglicherweise nicht ganz der Fall sind, aber es lohnt sich immer noch, nachzufragen.
—
Murph
@ Murph - Ich bin nicht der OP, aber in meiner Erfahrungsdokumentation wird nie das Detail erfasst, das ich will. Muss ich diesen Zustand bereinigen oder wird der Angerufene? Was genau ist das zu entkommen? Wie unterscheiden sich diese Überlastungen? Unterstützen diese Organisationen die Gleichstellung und wenn ja, auf welcher Grundlage? Was ist die ungefähre Komplexität dieses Aufrufs? Die einzige ausführliche Dokumentation, die es wert ist, zur Hand zu sein, ist die (saubere) Quelle, da es immer und allgemein Dinge gibt, die der Dokumentierer nie in Betracht gezogen hat, die Ihnen aber wichtig sind . Schlimmer noch, komplexe Dokumentationen enthalten unweigerlich Fehler und veralten.
—
Eamon Nerbonne