Debug/Release Binaries referenzieren

Hallo Gemeinde,

ich frage mich gerade welche geeignete und vor allem aktuelle Wege es gibt um einen Release Build mit Release Builds der Binaries außerhalb der Solution zu bauen und Debug Builds mit den Debug Binaries.
Von allen Binaries bin ich der Entwickler und mir steht auch der Sourcecode zur Verfügung, jedoch sind es Kernkomponenten, die ich in einer seperaten Solution entwickle. Wenn ich Änderungen an der Kernkomponente vornehme, möchte ich auch gerne die aktuelle Version für mein Projekt ziehen.

Ich hatte überlegt, das über Nuget Packages zu regeln, aber ich vermute, da gehört einiges an Arbeit dazu und VSTS scheint das in der Free Version nicht anzubieten.

Ich bin noch etwas unerfahren was Buildprozesse angeht, evtl. könnt ihr mir weiterhelfen.

Vielen Dank.

Hallo BlackMatrix,

wozu soll das gut sein? Wenn die Komponente getestet ist, so soll / kann auch die Release-Variante verwendet werden. Idealerweise per NuGet.

Sonst kannst du ein eigenes NuGet-Paket für Debug erstellen und per MsBuild-Konfig (csproj ist so ein) per Condition je nach Debug/Release das passende NuGet referenzieren.
Die Umsetzung davon hängt davon ab ob das neue MsBuild-Format (Microsoft.NET.Sdk) od. das klassische MsBuild verwendet wird.

Den Punkt bzgl. VSTS kann ich nicht nachvollziehen, ich kenn mich aber bei VSTS nicht recht gut aus. Aber "private" NuGet-Feeds kannst du z.B. auch lokal, bei MyGet, etc. haben und so sollte das kein Problem sein.

Für die Komponente kannst du CD (continuous deployment) verwenden und ein NuGet-Paket zum Feed pushen wenn ein check in (od. ein Tag) durchgeführt wird.
So kannst du die neueste Version folglich auch im anderen Projekt nutzen.

mfG Gü

Das VSTS Package Management ist kostenlos bis 5 Benutzer oder durch Besitz der Enterprise Lizenz.
Muss aber manuell hinzugefügt werden (VSTS Market Place).

MyGet hat keine kostenlosen Feeds mehr.

• Ein Build erstellt ein Artifact.
• Ein Release veröffentlicht ein Artifact.

Bei NuGet sieht das folgendermaßen aus:

• Ein Build erzeugt sowohl ein Beta- wie auch ein Stable-Package als Artifact (zwei Pakete!).
• Ein Release veröffentlicht zuerst auf einen **Beta-Feed **das Beta-Package. Sollte mit diesem alles OK sein, dann veröffentlicht anschließend das gleiche Release (weites Environment) das Stable-Package auf den Stable-Feed.

Der Sinn: die Assemblies müssen sowohl im Beta- als auch Stable-Package identisch sein.
Daher erzeugt der Build aus den gleichen Assemblies zwei Pakete; denn ein Paket kann entweder Beta sein ODER Stable. Ein Umswitchen ist da leider nicht möglich.
Daher der Weg über zwei Pakete auf zwei Feeds mit identischen Assemblies.

Ich hab dazu auch schon einen Blog-Artikel angefangen, aber noch nicht veröffentlicht.
Ist für die KW 1 in 2018 geplant. Da ist das dann auch detailliert beschrieben.

Sofern es Dir hilft kann ich Dir bis dahin nur Screenshots zeigen.

PS: wenn man alleine ist, dann kann man auch als das Release-Prinzip verzichten und direkt aus dem Build einfach auf den VSTS Channel pushen (mach ich für mich auch so - aber niemals in Projektumgebungen für Kunden/Teams).