Das musst Du einfach mal probieren.
Wenn Du nur auf B verweist, wird ja der Verweis auf A mitgebracht und es funktioniert.
Im Ernstfall hast Du einen Ring-Verweis, da musst Du neu ansetzen.

Haudruferzappeltnoch schrieb:

Wenn ich auf ein anderes Projekt verweise, kann ich dann dessen Verweise mitbenutzen?

Was soll das denn heissen?
Ein Projekt nutzt seine Verweise. Es nutzt nicht die Verweise anderer Projekte.

Haudruferzappeltnoch schrieb:

Sagen wir Projekt A hat die Klasse Foo
Projekt B hat die Klasse Bar, in der zum Beispiel ein Foo Rückgabewert einer Funktion ist (verweist also auf A)
In Projekt C müsste ich jetzt auf Projekt B und auf Projekt A verweisen damit ich die Funktion nutzen kann. B für den Aufruf von Bar, A für das Handling von Foo

Jetzt ist ja zweimal auf A verwiesen, wirkt redundant.

Ist es aber nicht.
Das ist ja das schöne an Verweisen, dass sie keine Kopie erstellen, sondern eben nur verweisen. Und wenn 10 Projekte auf A verweisen, so ists doch immer nur ein und dasselbe A.

Haudruferzappeltnoch schrieb:

Wahrscheinlich muss ich in B schon mit Foo weiterarbeiten, damit ich Foo nicht als Rückgabewert habe?

Ja, solche Überlegungen sind sinnvoll.
Es ist immer anzustreben, mit möglichst wenig Verweisen auszukommen (aber nicht weniger). (In diesem Zusammenhang nennt man Verweise auch "Abhängigkeiten".)
Da ist es manchmal unschön, wenn eine Bibliothek ihre Nutzer zwingt, noch andere Bibliotheken einzubinden, weil sie sonst garnet funzt.
Aber Kirche im Dorf lassen.
System.Windows.Forms zB setzt auch vorraus, dass System.Drawing eingebunden ist.

Sowas nennt man Architektur oder auch Anwendungs-Design.
Hauptzweck der Verweiserei ist natürlich Redundanz-Freiheit.
Das erkauft man sich durch Abhängigkeiten, aber wenn mans geschickt anstellt nur wenige.

Man muss sich beim Design einer Bibliothek genau ihren Zweck überlegen, und ausserdem beachten, wie allgemeingültig sie sein soll.
Ich hab zB GeneralHelpers, eine ganz allgemein-nützliche Lib, mit selber nur Basic-Abhängigkeiten (System, System.Core, System.Xml)
Dann habich WinFormHelpers und WpfHelpers mit je ihren Abhängigkeiten. Beide verweisen auch auf GeneralHelpers.
Also wenn ich eine WinForms-App baue, binde ich GeneralHelpers + WinFormsHelpers ein, und schaffe dadurch keine zusätzlichen Abhängigkeiten, weil meine App sowieso denselben WinForms-Kram braucht, mit dem auch die WinformHelpers hantieren.
Dann gibts noch DbPersistance. Die ist ebenso "unabhängig" wie GeneralHelpers, aber ich hab den Kram trotzdem nicht in GeneralHelpers reingepackt, weil ich sehr oft auch Anwendungen bastel, die garkeine Db benötigen.

---

Übrigens neuerdings habich den GeneralHelpers auch eine Json-Abhängigkeit zugefügt, aber bins auch fast schon wieder leid.
So Json-Darstellungen beliebiger (eher kleiner) Objekte sind zwar super-Schnuckelig, aber dafür andauernd ein Nuget-Gschiss, wenn ich meine Werke mal woanners laufen haben will.