Bereits mit Visual Studio 2013 Update 2 und einer Extension konnte Code über mehrere Projekte geteilt werden. Mit Visual Studio 2015 steht diese Funktion und das damit verbundene Projekttemplate von Haus aus zur Verfügung. Das Teilen einer gemeinsamen Codebasis innerhalb Solutions kann nun einfach und visuell erfolgen. Doch was sind die Unterschiede von Shared Projects und wie verhalten sich diese?
Was sind Shared Projects?
Shared Projects sind in Visual Studio 2015 eigenständige Projekttemplates und können einer Solution hinzugefügt werden. Ein Shared Project kann als eine Art Container für Dateien betrachtet werden, der innerhalb einer Solution geteilt und in einem eigenen Projekt verwaltet wird.
Shared Projects haben ein eigenes Projekticon, wodurch sie leicht zu unterscheiden sind von herkömmlichen Referenzen. Auch werden sie im Visual Studio als eigener Referenztyp behandelt und können so von den anderen Referenzen getrennt eingebunden werden.
Was ist der Unterschied?
Der geteilte Code kann von verschiedenen Anwendungsprojekten referenziert werden. Er wird als Teil der Projektreferenz kompiliert und kann compilerspezifische Anweisungen beinhalten. Shared Project generieren keine Assembly als Output (DLL/Exe) und damit auch keine eigenständige Version. Die gemeinsame Codebasis wird als Teil der referenzierten Software ausgeliefert.
Was ist der Vorteil?
Die Wiederverwendung von Code bei gleichzeitigem Multiplattformsupport ist heutzutage eine häufige Anforderung, welche nicht leicht umzusetzen ist. Soll Code für mehrere Plattformen verwendet werden, muss die Entwicklungsplattform Möglichkeiten anbieten dies umzusetzen. Shared Projects sind eine dieser Möglichkeiten und erlauben Software-Architekturen, das Teilen einer gemeinsamen Codebasis und Verwendung plattformspezifischer Elemente.
Was sind die Nachteile
Da ein Shared Project keinen eigenen Output besitzt, sollte er auch nur innerhalb einer Solution geteilt werden. Betrachtet man das Thema Release Management und muss eigenständige Versionen einer solchen gemeinsamen Codebasis anbieten, stellt sich schnell die Frage, ob der fehlende Output kein Nachteil ist. Sollte der Code dieser Art auf einer größeren Ebene geteilt und von verschiedenen unabhängigen Stellen referenziert und konsumiert werden, so muss für die Veröffentlichung dieses geteilten Codes eine eigene Versionsnummer existieren, welche Shared Projects nicht bieten.
Fazit
Shared Projects sind eine neue Art der Bündelung einer Codebasis und helfen, gemeinsam verwendeten Code als solchen darzustellen und anderen Projekten bereitzustellen. Die Verwendung von plattformspezifischen Direktiven ermöglicht eine hohe Integration für den geteilten Code. Unterliegt der geteilte Code jedoch einem eigenen Prozess zur Veröffentlichung, so kann eher weniger auf die eigene Versionierung verzichtet werden.