Wir haben ein .NET Projekt bestehend aus mehreren Teilprojekten (ca. 20). Es gibt mehrere Lösungen, die jeweils nur diejenigen Teilprojekte enthalten, die für die jeweilige Lösung relevant sind.
Um beliebige Lösungen zu ermöglichen, referenzieren unsere Teilprojekte niemals durch Projektreferenzen, sondern durch direkte DLL-Referenzen. Es gibt wenig Feinabstimmung der csproj-Datei, damit HintPath $ (Configuration) einbezieht, also baut Debug Debug-DLLs auf, und release baut Referenz Release-DLLs auf.
Alles funktioniert gut, aber es gibt zwei große Probleme - eins ist nervig und ein anderes ist wirklich akut:
Ich suche nach einem Rat von Leuten da draußen, die DLL-Referenzen wie uns benutzen und diese beiden Probleme irgendwie überwunden haben. Danke.
BEARBEITEN:
Beachten Sie, dass neben dem "Browse to Definition" -Problem die Verwendung von Dll-Referenzen anstelle von Projektreferenzen nur einmalige Kosten für den Projektmanager verursacht - das heißt, die Projektabhängigkeiten jeder betroffenen Lösung zu aktualisieren, wenn ein neues Projekt hinzugefügt wird eine neue Abhängigkeit muss eingeführt werden. Diese Projektabhängigkeiten werden in der SLN-Datei beibehalten und erfordern keine Wartung, bis ein neues Projekt eintrifft oder eine neue Abhängigkeit erstellt wird, was nicht allzu oft passiert.
Wir verwenden msbuild zum Erstellen unserer Projekte auf dem CI-Server, der dieselben .sln-Dateien verwendet wie VS. Es gibt eine Hauptdatei .sln, die alle Unterprojekte enthält.
Ich möchte das akutere Problem hervorheben - die Unfähigkeit, zu einer Definition in einem anderen Projekt zu navigieren, obwohl beide Projekte in derselben Lösung sind, nur weil die Referenzen DLL-Referenzen sind. Das ist ärgerlich und es ist ein Ärgernis, es gibt keinen Grund, warum VS auf Projektreferenzen besteht, um das Feature zu aktivieren. Andere Tools wie Resharper oder Visual Assist haben diese Einschränkung nicht. Leider haben wir diese Werkzeuge nicht und werden es kaum in der beobachtbaren Zukunft haben.
Das Problem mit Ihrer Build-Konfiguration ist folgender: Sagen wir, Sie haben 3 Projekte und 2 Lösungen.
%Vor%Plötzlich wird durch das Erstellen von Solution2 der Teil des Codes für Solution1 erstellt und in einem ungültigen Zustand belassen (die neuesten Binärdateien sind entweder nicht kompatibel oder mussten nicht erstellt werden).
>Jedes Projekt sollte in einer einzigen Lösung enthalten sein. Andere Lösungen können sich darauf verlassen, sollten aber den Code dieser Projekte nicht aktiv ändern. Auf diese Weise können sie auf eine erstellte DLL verweisen, da es keinen Grund gibt, die externen Abhängigkeiten neu zu erstellen.
Zusammenfassend sollten Sie sich etwas Zeit nehmen und Ihre Lösungen neu strukturieren, um die folgenden Bedingungen zu erfüllen:
Zusätzlich zu dem oben genannten empfehle ich, ein "Externals" -Verzeichnis zu erstellen, um Builds zu platzieren, wenn sie von anderen Lösungen referenziert werden. Nehmen wir an, Sie restrukturieren wie folgt:
%Vor% In diesem Fall würden Sie Kopien von Project1.dll und Project1.pdb in Externals\Project1\Debug und Externals\Project1\Release und Referenz External\Project1$(Configuration)\Project1.dll in Project3 platzieren. Aktualisieren Sie nur die Builds im Verzeichnis Externals, wenn Sie bereit sind, den Build für alle anderen Lösungen zu verwenden.
Es klingt für mich so, als ob die Probleme, denen Sie begegnen, das direkte Ergebnis sind, wenn Sie Ihr Werkzeug falsch benutzen. Visual Studio hat keine andere Möglichkeit, Projektabhängigkeiten automatisch zu berechnen, wenn Sie sie nicht verwalten lassen.
Es klingt, als hätten Sie zwei Möglichkeiten.
Es hört sich so an, als hätten Sie die Option # 1 ausgeschlossen, deshalb werde ich das nicht mehr behandeln. Damit bleibt nur die Option # 2 übrig.
Sie könnten NAnt verwenden, um Ihre individuellen CSproj-Projekte zu erstellen und Ihr NAnt-Build-Skript zu verwenden, um die Abhängigkeiten zwischen Projekten zu definieren. Es gibt zwei Nachteile.
Auf der zweiten Seite wäre Visual Studio nicht in der Lage, Ihre Lösung als Ganzes zu kompilieren, da diese Logik aus VS in ein externes Build-Skript verschoben worden wäre. Dies könnte zu Verwirrung zwischen den Entwicklern führen und würde den Debugging-Prozess behindern. Nicht zu sagen, dass diese Dinge nicht bewältigt werden können ... nur zu sagen, dass es bei diesen Schritten des Entwicklungsprozesses extra Setups geben würde.
Tags und Links .net visual-studio-2008 project-reference