Allgemein Für Administratoren Für Architekten Für Entwickler Für Projektleiter Für Tester News Produkte Publikationen
X
Marcel Isenmann
ist Software Process Consultant, Autor und Referent im Umfeld Microsoft ALM bei der AIT GmbH & Co. KG Stuttgart.

Marcel Isenmann

Neu in VS 2015 – Shared Projects

Montag, 17. August 2015

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.

13-08-2015 15-28-31

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.

13-08-2015 17-02-40

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.

untitled

Quelle: http://developer.xamarin.com/guides/cross-platform/application_fundamentals/pcl/introduction_to_portable_class_libraries/

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.

Weiterführende Informationen:

Verwandte Artikel:

Benötigen Sie Unterstützung bei der Software-Entwicklung und Architektur von .NET basierten Lösungen oder bei Einführung und Anpassung von Visual Studio / Microsoft Test Manager / Team Foundation Server?

Wir stehen Ihnen unter info(at)aitgmbh.de gerne zur Verfügung.

Tags: , , ,

Hinterlasse eine Antwort