Wer bereits in einem größeren Projekt gearbeitet hat, kennt es bestimmt: je größer die Anzahl an Projekten in einer Visual Studio Solution ist, desto schwerfälliger wird die Arbeit. Dies liegt einerseits daran, dass die Übersicht verloren geht; andererseits steigen die Lade- und Build-Zeiten an.

Gerade Solutions, die schon ein paar Jahre auf dem Buckel haben, wachsen mit der Zeit oft um immer weitere Projekte an, weil die Arbeit in einer Solution als der einfachste Weg erscheint, anstatt zwischen Solutions zu wechseln.

In diesen und den folgenden Blogeinträgen fassen wir Tipps und Erfahrungen zusammen, die die Arbeit in solchen Solutions erleichtern.

Visual Studio Solutions und Projekte

Bevor wir in die Details starten, beginnen wir mit einem kurzen Überblick über Solutions und Projekte: Visual Studio Projekte sind die Einzelkomponenten einer Anwendung und werden in Dlls oder Exe-Dateien übersetzt. Die Einstellungen zu einem Projekt und die enthaltenen Dateien werden in der Projektdatei (_.csproj bzw. _.vbproj) abgelegt.

Eine Solution gruppiert Projekte. Im Visual Studio wird in aller Regel auf Basis einer Solution gearbeitet. Auch für einzelne Projekte wird eine Solution angelegt, auch wenn VB.NET dies zur Vereinfachung manchmal anders darstellt. Neben den Binärreferenzen auf kompilierte Assemblies können Projekte andere Projekte innerhalb einer Solution als Projektverweis referenzieren. Dadurch kann das Projekt auf den veröffentlichten Code eines anderen Assemblies zurückgreifen.

Beim Build* werden die Projekte in der Solution nacheinander gebaut. Die Reihenfolge wird anhand der Abhängigkeiten bestimmt, so dass referenzierte Projekte vor den Projekten gebaut werden, die auf ihnen aufbauen. Bei Projektverweisen verwendet ein Projekt also immer den aktuellen Code-Stand der von ihm referenzierten Projekte in der Solution.

Vorteile bei der Arbeit innerhalb einer Solution

Dass die Entscheidung, neue Projekte in der gleichen Solution anzulegen, so populär ist, hat natürlich seine Gründe. Zum einen kann man schnell von einem Projekt ins nächste navigieren, einerseits beim Programmieren, andererseits aber auch beim Debuggen. Dies beschleunigt den Entwicklungsablauf natürlich deutlich.

Außerdem verwenden die Projekte in der Solution immer auf einfache Art und Weise den jeweils aktuellsten Stand der referenzierten Projekte, wohingegen dies bei Binärreferenzen mitunter aufwändiger ist. Sehr wertvoll ist darüber hinaus, dass Zirkelreferenzen zwischen den Projekten einer Solution unmöglich sind.

Auch beim Refactoring, also bei größeren Umstellungen in der Solution, ist es natürlich von Vorteil, wenn alle betroffenen Projekte in einer Solution liegen, so dass Build-Fehler schnell auffallen und behoben werden können.

Ab wann wird der Umgang mit einer Solution schwierig?

Hierfür kann man mehrere grobe Richtwerte ansetzen. Zum einen ist es wichtig, den Überblick über eine Solution behalten zu können. Bei Anwendung der Tipps aus dem folgenden Beitrag sind Solutions mit bis zu 30 Projekten in der Regel relativ unproblematisch, wenn aus Sicht der Softwarearchitektur aber auch nicht unbedingt wünschenswert.

Eine echte Beeinträchtigung der Arbeit haben wir bei Solutions mit mehr als 50 Projekten festgestellt, weil die Build-Zeiten deutlich angestiegen sind und es andererseits natürlich auf der Hand liegt, dass für die tägliche Entwicklungsarbeit nur ein Teil der Projekte relevant war. Spätestens dann sollten Gegenmaßnahmen ergriffen werden, um die Anzahl der Projekte zu reduzieren.

Ausblick

In den folgenden Artikeln zu dieser Serie betrachten wir, wie Sie

• Den Überblick über eine Solution behalten.
• Die Arbeit in einer Solution beschleunigen können.
• Große Solutions aufteilen können.

---