HowTo: “PublishedApplications” mit MSBuild & dem TFS für Windows Services / DLLs

Wir benutzen bei uns für den Build Prozess MSBuild und nutzen den Team Foundation Server. Wer eine ASP.NET Applikation baut bekommt diese in einem “PublishedWebsites” Ordner serviert. Jegliche andere Sachen werden aber einfach ins Bin/Release Verzeichnis kopiert. Da das nicht gerade besonders hilfreich ist, kann man das natürlich auch ändern – allerdings mit etwas basteln.

Was muss man tun um die Ordnerstruktur beizubehalten?

Eigentlich möchte man ja pro Applikation einen eigenen Output Folder haben. Leider baut der TFS alles und kopiert das Ergebnis einfach ins Release Verzeichnis.
In unserem Beispiel haben wir eine TFSBuild.proj Datei, welche momentan 3 Solutions baut.
Die Solutionnames sind bei uns natürlich etwas anders

• “Websolution1” enthält im Großen und Ganzen eine ASP.NET MVC Webseite.
• “Websolution2” enthält einen Webservice
• “WindowsSolution1” enthält einen Windows Dienst und einige andere Klassenbibliotheken.

Der TFS legt automatisch für ASP.NET Projekte einen “PublishedWebsites” Ordner an.

Hier mal direkt einen Ausschnitt aus dem TFSBuild.proj File:

    <SolutionToBuild Include="$(BuildProjectFolderPath)/../../Main/Source/Websolution1.sln">
        <Targets></Targets>
        <Properties>OutDir=$(OutDir)</Properties>
    </SolutionToBuild>
    <SolutionToBuild Include="$(BuildProjectFolderPath)/../../Main/Source/Websolution2.sln">
        <Targets></Targets>
        <Properties>OutDir=$(OutDir)</Properties>
    </SolutionToBuild>
    <SolutionToBuild Include="$(BuildProjectFolderPath)/../../Main/Source/WindowsSolution1.sln">
      <Targets></Targets>
      <Properties></Properties>
    </SolutionToBuild>
  </ItemGroup>

  <PropertyGroup>
    <CustomizableOutDir>true</CustomizableOutDir>
  </PropertyGroup>

Wichtig ist die untere PropertyGroup und das der Wert “CustomizableOutDir” auf “true” gesetzt ist. Damit wird im Grunde der Default-Mechanismus des TFS ausgeschalten. Daher muss man in den Properties das OutDir mitgeben. Da es bei den Webseiten keine Problem gab setzt ich es wieder zum Standard.

Nun geht man in die Projektdatei von dem Windowsservice (welche in der WindowsSolution1) ist. Dort hab ich es wie folgt angepasst:

  <PropertyGroup>
    <PublishedApplicationOutputDir Condition=" '$(TeamBuildOutDir)'!='' ">$(TeamBuildOutDir)_PublishedApplications\$(MSBuildProjectName)</PublishedApplicationOutputDir>
    <PublishedApplicationOutputDir Condition=" '$(TeamBuildOutDir)'=='' ">$(MSBuildProjectDirectory)</PublishedApplicationOutputDir>
  </PropertyGroup>

  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
    <DebugType>pdbonly</DebugType>
    <Optimize>true</Optimize>
    <OutputPath>$(PublishedApplicationOutputDir)</OutputPath>
    <DefineConstants>TRACE</DefineConstants>
    <ErrorReport>prompt</ErrorReport>
    <WarningLevel>4</WarningLevel>
  </PropertyGroup>

Wenn es vom TeamBuild gebaut wird gibt der TFS die Property TeamBuildOutDir mit rein und setzt entsprechend meinen gewünschten “PublishedApplication” Pfad.

Das ganze wird am Ende als OutputPath bestimmt und schon haben wir pro Windowsdienst / Klassenbibliothek etc. einen eigenen Output-Folder.

Meine Lösung stammt ursprünglich von diesem Blogpost. Hintergrund für das CustomizableOutDir Verhalten kann man in diesem Blogpost nachlesen.

Wenn man auf das Datum der Blogposts schaut, sieht man, dass das Problem schon etwas älter ist, aber ich bin jetzt erst drauf gestoßen

MSBuild

Wer einen Einstieg in MSBuild sucht, der findet eine klasse Serie auf Thorsten Hans seinem Blog: Das MSBuild Universum

PS: Natürlich geb ich keine Garantie ab, dass dies die ideale Lösung ist. Aber es baut erstmal

About the author

Written by Robert Mühsig

Robert Mühsig (@robert0muehsig) ist Webentwickler und beschäftigt sich mit Web-Frameworks (vor allem dem ASP.NET MVC Framework) und scheut sich auch nicht vor Javascript. Ansonsten bloggt er über all jene Probleme, die ihm über den Weg laufen. Seit 2008 ist er Microsoft MVP für ASP.NET und er arbeitet bei der T-Systems Multimedia Solutions GmbH in Dresden. Treffen kann man ihn online via Twitter (@robert0muehsig) oder dieser Seite oder bei der .NET User Group Dresden.