I am leaving Microsoft after 14 years: my last official day will be 27th of December. I will continue to be part of ALM Rangers, and contribute to the community.

This blog moves to https://blog.casavian.eu/ and you may contact me through LinkedIn or Twitter.

A final note. Many loved my last e-mail, so here it is.

Farewell and goodbye.

Cos’è XmlPreprocess

Nelle parole dell’autore “XmlPreprocess is a command-line utility that can modify annotated XML files much like a code preprocessor. It is useful for deploying configuration files to different environments making substitutions such as connection strings”. Si può scaricare, inclusi sorgenti e documentazione da https://xmlpreprocess.codeplex.com/.

Figura 1 – Funzionamento di XmlPreprocess

Come si vede in Figura 1, il tool legge da un foglio Excel i valori di configurazione che sostituisce nel file che riceve in input.

In questo esempio utilizziamo il file Excel, ma il tool è in grado di usare altre fonti come, ad esempio, un database.

Disegno della soluzione

L’esempio assume la presenza di due file essenziali: l’eseguibile XmlPreprocess.exe e il file SettingsSpreadsheet.xml che contiene i valori da sostituire.

Il primo, l’eseguibile, deve trovarsi nella stessa cartella del workflow di build (build process template).

Il secondo è opportuno venga conservato in una cartella speciale con ristretti permessi di sicurezza, in modo che possa accedervi solo il servizio di build e il personale che ha in gestione i sistemi e che ha quindi la responsabilità delle configurazioni e delle password.

Il tool viene lanciato al termine della compilazione e dello unit test, quando tutti gli artefatti sono giunti nello share di Drop: in questo modo i file di configurazione ivi contenuti sono pronti per essere installati in un ambiente target senza ulteriori passaggi.

Personalizzazione del workflow di build

Il workflow personalizzato è un clone del Default template.

Abbiamo aggiunto due argomenti supplementari (v. Figura 2): il primo, TargetEnvironment, indica da quale ambiente, censito nel file Excel, prenderemo i valori per la sostituzione; il secondo, SettingsSpreadsheetPath, è il percorso completo del file Excel, espresso come version control path, ossia quelli che iniziano con $.

Figura 2 – Argomenti supplementari del workflow

È stata aggiunta una sezione (sequenceActivity) nell’ambito (scope) “Run on Agent” come ultimo passo, dopo che gli eseguibili sono stati prodotti nella cartella di Drop; la sezione si chiama “*** Apply XmlPP” (gli asterischi aiutano a identificare la personalizzazione.

Figura 3 – Personalizzazione del workflow di build

La sequenza di azioni è:

1. calcolo dove si trova l’eseguibile di XmlPreprocess — la proprietà ServerPath ci fornisce il percorso, in termini di version control, del template di build che viene convertito in un percorso locale mediante ConvertWorkspaceItem; da questo si ricava la cartella contenente e quindi il percorso locale assoluto dell’eseguibile
2. scarico dal version control il file Excel — con l’activity DownloadFiles lo portiamo in locale nella stessa cartella dove si trova
3. cerco tutti i file .config
4. richiamo XmlPreprocess per ciascun file

Il sorgente è riportato nel Listato 1.

<Sequence DisplayName="*** Apply XmlPP">
  <Sequence.Variables>
    <Variable x:TypeArguments="x:String" Name="localPathToXmlPP" />
    <Variable x:TypeArguments="scg:IEnumerable(x:String)" Name="configFiles" />
    <Variable x:TypeArguments="x:String" Name="localPathToSpreadsheet" />
  </Sequence.Variables>
  <mtbwa:ConvertWorkspaceItem DisplayName="Convert BuildTemplate path to local" Input="[BuildDetail.BuildDefinition.Process.ServerPath]" Result="[localBuildTemplatePath]" Workspace="[Workspace]" />
  <Assign DisplayName="Assign localPathToXmlPP">
    <Assign.To>
      <OutArgument x:TypeArguments="x:String">[localPathToXmlPP]</OutArgument>
    </Assign.To>
    <Assign.Value>
      <InArgument x:TypeArguments="x:String" xml:space="preserve">[System.IO.Path.Combine(
System.IO.Path.GetDirectoryName(localBuildTemplatePath),
"XmlPreprocess.exe")]</InArgument>
    </Assign.Value>
  </Assign>
  <Assign DisplayName="Assign localPathToSpreadsheet">
    <Assign.To>
      <OutArgument x:TypeArguments="x:String">[localPathToSpreadsheet]</OutArgument>
    </Assign.To>
    <Assign.Value>
      <InArgument x:TypeArguments="x:String" xml:space="preserve">[System.IO.Path.Combine(
  System.IO.Path.GetDirectoryName(localBuildTemplatePath),
  "SettingsSpreadsheet.xml")]</InArgument>
    </Assign.Value>
  </Assign>
  <mtbwa:DownloadFiles DeletionId="{x:Null}" DisplayName="Download SettingsSpreadsheet.xml" LocalPath="[localPathToSpreadsheet]" ServerPath="[SettingsSpreadsheetPath]" mva:VisualBasic.Settings="Assembly references and imported namespaces serialized as XML namespaces" />
  <mtbwa:FindMatchingFiles DisplayName="Find *.config Files" MatchPattern="[String.Format(&quot;{0}\**\*.config&quot;, DropLocation)]" Result="[configFiles]" />
  <ParallelForEach x:TypeArguments="x:String" DisplayName="Run XmlPP for Each .config" Values="[configFiles]">
    <ActivityAction x:TypeArguments="x:String">
      <ActivityAction.Argument>
        <DelegateInArgument x:TypeArguments="x:String" Name="configFile" />
      </ActivityAction.Argument>
      <mtbwa:InvokeProcess Arguments="[String.Format(&quot;/input:{0} /spreadsheet:{1} /environment:{2}&quot;, configFile, localPathToSpreadsheet, TargetEnvironment)]" DisplayName="XmlPreprocess" FileName="[localPathToXmlPP]">
        <mtbwa:InvokeProcess.ErrorDataReceived>
          <ActivityAction x:TypeArguments="x:String">
            <ActivityAction.Argument>
              <DelegateInArgument x:TypeArguments="x:String" Name="errOutput" />
            </ActivityAction.Argument>
          </ActivityAction>
        </mtbwa:InvokeProcess.ErrorDataReceived>
        <mtbwa:InvokeProcess.OutputDataReceived>
          <ActivityAction x:TypeArguments="x:String">
            <ActivityAction.Argument>
              <DelegateInArgument x:TypeArguments="x:String" Name="stdOutput" />
            </ActivityAction.Argument>
          </ActivityAction>
        </mtbwa:InvokeProcess.OutputDataReceived>
      </mtbwa:InvokeProcess>
    </ActivityAction>
  </ParallelForEach>
</Sequence>

Listato 1 – XAML della personalizzazione

Per maggior sicurezza si può aggiungere un quinto passo per cancellare il file Excel dall’area di lavoro della build.

Purtroppo non esiste una activity ‘primitiva’ per la cancellazione, ma la soluzione è semplicissima.

Figura 4 – Aggiunta della cancellazione del file Excel

L’ azione è semplicemente:

5. chiamo il metodo File.Delete per il file Excel

Il sorgente è riportato nel Listato 2.

<InvokeMethod DisplayName="Delete local Spreadsheet" MethodName="Delete" TargetType="si:File">
  <InArgument x:TypeArguments="x:String">[localPathToSpreadsheet]</InArgument>
</InvokeMethod>

Listato 2 – XAML cancellazione finale

Come deve esser fatta la definizione di una build

La definizione per la build non è molto diversa dal quella di default.

Figura 5 – Definizione della build

I tre elementi da cambiare sono evidenziati in Figura 1: si sceglie il Build process template personalizzato e si inseriscono i valori desiderati per indicare il file Excel da usare per le sostituzioni e l’ambiente destinatario.

È importantissimo che il workspace comprenda la cartella con Build process template, come indicato in Figura 6.

Figura 6 – Workspace che include il Build template

In caso contrario la build termina con un errore simile a questo

1 error(s), 0 warning(s)

Exception Message: There is no working folder mapping for $/EsperimentiBuild/BuildProcessTemplates/XmlPreprocess/XmlPreprocessBuildProcessTemplate.xaml. (type ItemNotMappedException)Exception Stack Trace: at Microsoft.TeamFoundation.VersionControl.Client.Workspace.GetLocalItemForServerItem(String serverItem, Boolean detectImplicitCloak) at Microsoft.TeamFoundation.Build.Workflow.Activities.ConvertWorkspaceItem.Execute(CodeActivityContext context) at System.Activities.CodeActivity`1.InternalExecute(ActivityInstance instance, ActivityExecutor executor, BookmarkManager bookmarkManager) at System.Activities.Runtime.ActivityExecutor.ExecuteActivityWorkItem.ExecuteBody(ActivityExecutor executor, BookmarkManager bookmarkManager, Location resultLocation)

Una build che si conclude correttamente, avrà invece un log simile a quello in Figura 7.

Figura 7 – Build Log favorevole

In un log dettagliato potremo vedere una riga simile a questa

X:\Builds\1\EsperimentiBuild\XmlPreprocess_Dev\src\BuildProcessTemplates\XmlPreprocess\XmlPreprocess.exe /input:\\gvtfs12\drops\XmlPreprocess_Dev\XmlPreprocess_Dev_20130131.6\ConsoleApplication1.exe.config /spreadsheet:X:\Builds\1\EsperimentiBuild\XmlPreprocess_Dev\src\BuildProcessTemplates\XmlPreprocess\SettingsSpreadsheet.xml /environment:Integration

Conclusioni

L’esempio può essere immediatamente usato al fine di predisporre i file di configurazione, che si trovano nello share di Drop, per uno specifico ambiente target. Con più build definition preparo i pacchetti per ambienti differenti.

In generale, si son viste delle tecniche utili per integrare il lancio di un tool eseguibile all’interno del processo di build: calcolo di dove si trova l’eseguibile, messa in sicurezza di dati, individuazione di file da elaborare.

Il codice è applicabile sia a Team Foundation Server 2010 che 2012 che a Team Foundation Service.

Why WSDL?

WSDL is the standard for describing a web service, it roots back to end of ‘90s; being a standard, it could be used to exchange contracts between teams. In .NET svcutil.exe can be used to go both ways: generate WSDL from contract interfaces contained in an assembly or the proxy code from the WSDL.

But… there are always exceptions: in .NET 4.0 you may expose a Windows Workflow (WF) as a WCF Service and the contract is dynamically generated. In such cases, when the contract is built on the fly, the WSDL can be obtained only querying the running service.

IIS Express

I opted to use this tool as it is a good replica of IIS but you can avoid any kind of permanent registration and leave your build server clean. You can launch and configure it to host a web service from the command line (see https://www.iis.net/learn/extensions/using-iis-express/running-iis-express-from-the-command-line). It has two modes of operation: the first mode is implies managing an applicationhost.config file, while the second mode requires only the path to the service’s folder. I opted for this latter with these options:

iisexpress /path:path-to-the-service /port:a-fixed-port-number-chose-by-the-build /clr:v4.0 /systray:false

Exporting the WSDL

To export the WDSL, I implemented a couple of classes. The first class IISExpress is based on the ideas found here: using System.Diagnostics.Process class to launch IIS Express and using a Windows message to quit. The second class WsdlManager is the workhorse. It uses System.ServiceModel.Description.MetadataExchangeClient to get the wsdl from the service and it fix-up the URIs embedded in it so the cross-file references use relative URLs instead of absolute URLs. This way, the saved data will be correctly interpreted later.

Wrapping the code in a task

I put the two classes in an MSBuild task named ExportWSDL contained in AutoWSDL.dll. The main reason is to be able to run the code for each interesting project compiled during the build. But how can we identify the projects that contain a service? I looked up for 32f31d43-81cc-4c15-9de6-3fc5453562b6 (Workflow Foundation 4.0) or 3D9AD99F-2412-4246-B90B-4EAA41C64699 (Windows Communication Foundation) in the ProjectTypeGuids element for each project.

There is another issue: the task may receive a project or a solution: in this latter case we need to parse it. Annoyingly there is no documented way, but other people have already investigated for us (here and here).

The body of the task follows.

var si = SolutionInfo.Parse(this.SolutionFileName);
foreach (var pi in si.Projects)
{
    if (pi.Types.Contains(ProjectTypes.WorkflowFoundation40)
        || pi.Types.Contains(ProjectTypes.WindowsCommunicationFoundation))
    {
        Log.LogMessage(MessageImportance.Low, "Launching IIS Express for {0}", pi.ProjectName);
        using (var iis = IISExpress.StartApplication(pi.ProjectRoot, this.Port, 4.0))
        {
            var wm = new WsdlManager(this.OutputFolder);
            var services = new List<string>();
            services.AddRange(pi.GetFilesOfInterest(".xamlx"));
            services.AddRange(pi.GetFilesOfInterest(".svc"));
            foreach (var service in services)
            {
                string wsdlUrl = string.Format(@"https://localhost:{0}/{1}?wsdl", this.Port, service);
                var serviceName = System.IO.Path.GetFileNameWithoutExtension(service);
                Log.LogMessage(MessageImportance.Low, "Getting WSDL for {0}", serviceName);
                wm.MaterializeWsdl(serviceName, new Uri(wsdlUrl));
            }//for
        }//using
    } else {
        Log.LogMessage(MessageImportance.Low, "Project {0} is not a Web service", pi.ProjectName);
    }//if
}//for

As you see, I adopted the simple heuristic that each Xamlx and Svc file exposes a web service.

This task takes three parameters

At this point we have an MSBuild task that given a project or solution file, analizes it and get the WSDL for each available service.

Hooking the Visual Studio compile

An elegant way to use this task is to extend the normal Visual Studio build process, in such a way that built the binaries we proceed to run them and get the WSDL metadata.

To trick to tie into the MSBuild architecture is the CustomAfterMicrosoftCommonTargets property: putting the path of an MSBuild file as its value, will trigger the parsing of such after the Microsoft.Common.targets which is at the core of all Visual Studio projects. In our case we use the PrepareForRunDependsOn target: at this point the DLLs are built and ready to execute.

Here is the content of the AutoWSDL.targets file to extend the VS build.

<Project xmlns="https://schemas.microsoft.com/developer/msbuild/2003"
    ToolsVersion="4.0" >
  <!-- hook end of compile -->
  <PropertyGroup>
    <PrepareForRunDependsOn>$(PrepareForRunDependsOn);ExportWSDL</PrepareForRunDependsOn>
  </PropertyGroup>
  <PropertyGroup>
    <WsdlHostingPort Condition="'$(WsdlHostingPort)'==''">44444</WsdlHostingPort>
  </PropertyGroup>
  <UsingTask TaskName="ExportWSDL" AssemblyFile="AutoWSDL.dll" />
  <Target Name="ExportWSDL">
    <PropertyGroup>
      <WsdlOutputFolder>$(OutDir)WSDL\$(MSBuildProjectName)\</WsdlOutputFolder>
    </PropertyGroup>
    <MakeDir Condition="!Exists($(WsdlOutputFolder))" Directories="$(WsdlOutputFolder)" />
    <ExportWSDL
      SolutionFileName="$(MSBuildProjectFullPath)"
      OutputFolder="$(WsdlOutputFolder)"
      Port="$(WsdlHostingPort)"
      />
  </Target>
</Project>

If we put in the same folder the two files, AutoWSDL.targets and AutoWSDL.dll, we can test from a Developer Command Prompt by running:

MSBuild <path_to_a_WCF_project>.csproj /p:CustomAfterMicrosoftCommonTargets=<path_to>AutoWSDL.targets

and find the exported WSDL files under the bin output folder.

Note that you may use this trick to extend in other ways the standard Visual Studio process.

The complete solution

The last logical step is to move from MSBuild to Team Foundation Server build, in order to have a single place for the WSDL contracts shared by the whole team. The nice part is to discover that all we have built before can be reused without changes.

The file AutoWSDLTemplate.xaml is a slightly modified version of the Default Template. It simply adds to the MSBuild Arguments the CustomAfterMicrosoftCommonTargets property.

In XAML code

<Sequence DisplayName="*** Hook CustomAfterMicrosoftCommonTargets">
  <Sequence.Variables>
    <Variable x:TypeArguments="x:String" Name="customAfterMicrosoftCommonTargets" />
    <Variable x:TypeArguments="x:String" Name="localBuildTemplatePath" />
  </Sequence.Variables>
  <sap:WorkflowViewStateService.ViewState>
    <scg:Dictionary x:TypeArguments="x:String, x:Object">
      <x:Boolean x:Key="IsExpanded">True</x:Boolean>
    </scg:Dictionary>
  </sap:WorkflowViewStateService.ViewState>
  <mtbwa:ConvertWorkspaceItem Input="[BuildDetail.BuildDefinition.Process.ServerPath]"
Result="[localBuildTemplatePath]" Workspace="[Workspace]" />
  <Assign>
    <Assign.To>
      <OutArgument x:TypeArguments="x:String">[customAfterMicrosoftCommonTargets]</OutArgument>
    </Assign.To>
    <Assign.Value>
      <InArgument x:TypeArguments="x:String" xml:space="preserve">[Path.Combine(
Path.GetDirectoryName(localBuildTemplatePath),
"AutoWSDL.targets")]</InArgument>
    </Assign.Value>
  </Assign>
  <Assign>
    <Assign.To>
      <OutArgument x:TypeArguments="x:String">[MSBuildArguments]</OutArgument>
    </Assign.To>
    <Assign.Value>
      <InArgument x:TypeArguments="x:String">[String.Format(
"{0} /p:CustomAfterMicrosoftCommonTargets={1} ", MSBuildArguments,
customAfterMicrosoftCommonTargets)]</InArgument>
    </Assign.Value>
  </Assign>
</Sequence>

The first step is to get the Server path of the running build worklow, convert it to a local path using the ConvertWorkspaceItem activity. Then assumes that the AutoWSDL.targets file resides in the same folder; finally adds the CustomAfterMicrosoftCommonTargets property to the list of MSBuild arguments.

This works as long as we have the three files in the same folder.

Final words

I think this is the kind of post that will tickle Mr. Fourie couriosity.

Giulio

Temo di averlo ripetuto alla nausea: la build incrementale è una faccenda molto delicata ed è facile combinare pasticci se non si controlla costantemente. Perciò ne sconsiglio, in generale l’impiego. Recentemente ho messo però insieme una ricetta che limita alcuni degli inconvenienti associati ad essa ed è questo l’argomento del post.

In questo post mostrerò come preparare un template di build personalizzato che incrementi indipendentemente i numeri di versione dei singoli progetti Visual Studio e ci permetta però di rintracciare con facilità la team build che ha prodotto gli eseguibili, come illustrato in figura.

Estendere la build dei progetti

Il primo tassello della soluzione è estendere la normale compilazione dei progetti Visual Studio (C#, VB o altro). Lavorare a livello MSBuild permette di conoscere se un determinato progetto è soggetto o meno a ricompilazione.

L’insieme dei file TARGETS che compone la compilazione .NET e Visual Studio prevede alcune utili proprietà, parzialmente documentate su Common MSBuild Project Properties. Parzialmente perché quella che preferisco, e ci servirà, è CustomAfterMicrosoftCommonTargets. Impostando tale proprietà MSBuild al percorso di un file Targets, questo viene aggiunto dinamicamente e possiamo cambiare la definizione di target già definiti o di estenderne il comportamento. Bello e pericoloso!

Il secondo tassello è scegliere uno strumento per modificare i contenuti dei file AssemblyInfo. Poiché l’attività va condotta a livello MSBuild la scelta naturale è di utilizzare il task AssemblyInfo da MSBuild Extension Pack (https://msbuildextensionpack.codeplex.com/); il task è contenuto in MSBuild.ExtensionPack.dll che, a sua volta, richiede Ionic.Zip.dll. Questo task ha moltissimi argomenti, tanto che gli sviluppatori hanno fornito il file MSBuild.ExtensionPack.VersionNumber.targets pronto per l’impiego.

Se mettiamo in una stessa cartella questi tre file possiamo già provare il funzionamento di base digitando, da un Developer Command Prompt, qualcosa del tipo:

MSBuild <path ad un progetto>.csproj /p:CustomAfterMicrosoftCommonTargets=<path_di>MSBuild.ExtensionPack.VersionNumber.targets

e vedere gli effetti di impostare valori diversi in MSBuild.ExtensionPack.VersionNumber.targets.

<!-- Properties for controlling the Assembly Version -->
<PropertyGroup>
    <AssemblyMajorVersion>1</AssemblyMajorVersion>
    <AssemblyMinorVersion>0</AssemblyMinorVersion>
    <AssemblyBuildNumber></AssemblyBuildNumber>
    <AssemblyRevision></AssemblyRevision>
    <AssemblyBuildNumberType>DateString</AssemblyBuildNumberType>
    <AssemblyBuildNumberFormat>MMdd</AssemblyBuildNumberFormat>
    <AssemblyRevisionType>AutoIncrement</AssemblyRevisionType>
    <AssemblyRevisionFormat>00</AssemblyRevisionFormat>
</PropertyGroup>

<!-- Properties for controlling the Assembly Version -->
<PropertyGroup>
    <AssemblyMajorVersion>1</AssemblyMajorVersion>
    <AssemblyMinorVersion>0</AssemblyMinorVersion>
    <AssemblyBuildNumber>0</AssemblyBuildNumber>
    <AssemblyRevision>0</AssemblyRevision>
</PropertyGroup>

<!-- Properties for controlling the Assembly File Version -->
<PropertyGroup>
    <AssemblyFileMajorVersion>1</AssemblyFileMajorVersion>
    <AssemblyFileMinorVersion>0</AssemblyFileMinorVersion>
    <AssemblyFileBuildNumber></AssemblyFileBuildNumber>
    <AssemblyFileRevision></AssemblyFileRevision>
    <AssemblyFileBuildNumberType>DateString</AssemblyFileBuildNumberType>
    <AssemblyFileBuildNumberFormat>MMdd</AssemblyFileBuildNumberFormat>
    <AssemblyFileRevisionType>AutoIncrement</AssemblyFileRevisionType>
    <AssemblyFileRevisionFormat>00</AssemblyFileRevisionFormat>
</PropertyGroup>

<!-- Properties for controlling the Assembly File Version -->
<PropertyGroup>
    <AssemblyFileMajorVersion>1</AssemblyFileMajorVersion>
    <AssemblyFileMinorVersion>0</AssemblyFileMinorVersion>
    <AssemblyFileBuildNumber></AssemblyFileBuildNumber>
    <AssemblyFileRevision>0</AssemblyFileRevision>
    <AssemblyFileBuildNumberType>AutoIncrement</AssemblyFileBuildNumberType>
    <AssemblyFileBuildNumberFormat>000</AssemblyFileBuildNumberFormat>
</PropertyGroup>

<!-- Propeties for controlling extended assembly attributes -->
<PropertyGroup>
    <AssemblyCompany></AssemblyCompany>
    <AssemblyConfiguration></AssemblyConfiguration>
    <AssemblyCopyright></AssemblyCopyright>
    <AssemblyCulture></AssemblyCulture>
    <AssemblyDescription></AssemblyDescription>
    <AssemblyProduct></AssemblyProduct>
    <AssemblyTitle></AssemblyTitle>
</PropertyGroup>

<!-- Propeties for controlling extended assembly attributes -->
<PropertyGroup>
    <AssemblyCompany>Fictious company</AssemblyCompany>
    <AssemblyConfiguration>$(ConfigurationName)</AssemblyConfiguration>
    <AssemblyCopyright>(c) Fictious company 2012</AssemblyCopyright>
    <AssemblyCulture></AssemblyCulture>
    <AssemblyDescription></AssemblyDescription>
    <AssemblyProduct>My product</AssemblyProduct>
    <AssemblyTitle></AssemblyTitle>
    <AssemblyInformationalVersion>$(TeamBuildNumber)</AssemblyInformationalVersion>
</PropertyGroup>

In breve la regola è di:

• Non alterare l’AssemblyVersion
• Aggiornare l’AssemblyFileVersion con un numero progressivo rappresentante la build della singola componente
• Riportare nell’AssemblyInformationalVersion la proprietà $(TeamBuildNumber)

In $(TeamBuildNumber) passeremo l’identificatore della team build che ha ricompilato il progetto. Per provare il meccanismo possiamo usare un comando come:

MSBuild <path ad un progetto>.csproj /p:CustomAfterMicrosoftCommonTargets=<path_di>MSBuild.ExtensionPack.VersionNumber.targets /p:TeamBuildNumber=pseudo-identificativo di build

Un template di build

Abbiamo visto a livello MSBuild come aggiornare automaticamente i file AssemblyInfo.cs (o .vb) dei progetti che vengono ricompilati senza modificare i file di progetto stessi (.csproj o .vbproj o simili); vediamo ora come inglobare queste modifiche in un template per la build di Team Foundation Server in modo che sia facilmente riutilizzabile.

L’intervento sul Default Template è minimo e non richiede custom activity ma è tutto a livello XAML, con il beneficio collaterale di non dover gestire il path degli assembly per le custom activities.

Anzitutto creiamo una cartella sotto BuildProcessTemplate del TeamProject e vi copiamo i tre file precedenti.

Ricordiamo infatti che la cartella (e le sottocartelle) contenenti il template vengono scaricate automaticamente dall’agent di build.

Creiamo un clone del default template.

A questo punto abbiamo predisposto tutti i file che servono.

Aggiungiamo un parametro che l’utente inserirà nella build definition, come da figura.

Il parametro zzzVersionNumberTargetsFile indica il file Targets da usare: in questo modo possiamo usare diverse regole in build definition diverse.

La seguente figura illustra il punto del workflow da alterare.

A livello di RunOnAgent aggiungiamo una Sequence che aggiunge dati alla variabile MSBuildArguments; il valore di questa è l’insieme di argomenti passati ad MSBuild al momento di compilare una solution od un project Visual Studio. Inoltre il file MSBuild.ExtensionPack.VersionNumber.targets viene cercato nella stessa cartella che contiene il template; la posizione della cartella viene determinata dalla activity ConvertWorkspaceItem.

Il codice XAML è abbastanza semplice da interpretare.

<Sequence DisplayName="*** Hook CustomAfterMicrosoftCommonTargets">
  <Sequence.Variables>
    <Variable x:TypeArguments="x:String" Name="customAfterMicrosoftCommonTargets" />
    <Variable x:TypeArguments="x:String" Name="localBuildTemplatePath" />
  </Sequence.Variables>
  <mtbwa:ConvertWorkspaceItem DisplayName="Convert BuildTemplate path to local" Input="[BuildDetail.BuildDefinition.Process.ServerPath]" Result="[localBuildTemplatePath]" Workspace="[Workspace]" />
  <Assign DisplayName="Assign customAfterMicrosoftCommonTargets">
    <Assign.To>
      <OutArgument x:TypeArguments="x:String">[customAfterMicrosoftCommonTargets]</OutArgument>
    </Assign.To>
    <Assign.Value>
      <InArgument x:TypeArguments="x:String" xml:space="preserve">[System.IO.Path.Combine(
System.IO.Path.GetDirectoryName(localBuildTemplatePath),
zzzVersionNumberTargetsFile)]</InArgument>
    </Assign.Value>
  </Assign>
  <Assign DisplayName="Append CustomAfterMicrosoftCommonTargets to MSBuildArguments">
    <Assign.To>
      <OutArgument x:TypeArguments="x:String">[MSBuildArguments]</OutArgument>
    </Assign.To>
    <Assign.Value>
      <InArgument x:TypeArguments="x:String">[String.Format("{0} /p:CustomAfterMicrosoftCommonTargets={1} ", MSBuildArguments, customAfterMicrosoftCommonTargets)]</InArgument>
    </Assign.Value>
  </Assign>
  <Assign DisplayName="Append TeamBuildNumber to MSBuildArguments">
    <Assign.To>
      <OutArgument x:TypeArguments="x:String">[MSBuildArguments]</OutArgument>
    </Assign.To>
    <Assign.Value>
      <InArgument x:TypeArguments="x:String">[String.Format("{0} /p:TeamBuildNumber={1} ", MSBuildArguments, BuildDetail.BuildNumber)]</InArgument>
    </Assign.Value>
  </Assign>
</Sequence> 
        

La proprietà MSBuild TeamBuildNumber viene valorizzata con BuildDetail.BuildNumber, ossia l’identificativo della build in corso, come abbiamo visto in precedenza.

Salvando tutto nel version control siamo pronti a definire dei profili di build basati su questo template personalizzato.

Definiamo le build

A questo punto creare una nuova build definition richiede solo un paio di accortezze.

Come spiegato in Define a Build Process that is Based on the Default Template, le build incrementali si basano sul valore del parametro Clean Workspace. Nel nostro esempio lo poniamo a None, cosicché solamente i file aggiornati nel version control sono portati nell’area di build e quindi solo i progetti strettamente necessari vengono ricompilati. La ricompilazione aggancia automaticamente la modifica del file AssemblyInfo.CS (o .VB). È possibile che la build non trovi necessario ricompilare alcun progetto e di conseguenza i binari prodotti siano identici a quelli della precedente build.

Dobbiamo inoltre valorizzare il parametro Targets File for Version Numbering con il nome del file MSBuild.ExtensionPack.VersionNumber.targets da usare. La scelta di rendere parametrico (e obbligatorio) il nome del file con le regole di incremento della versione ci permette di usare regole differenti per build definition diverse. Ad esempio un build definition che rilascia hotfix incrementerà il numero revision invece del build.

Finale

Un comodo ritocco al nostro template custom è di porre a None il valore di default per Clean Workspace, così da non doverlo cambiare ad ogni nuova definizione.

Inoltre possiamo accorgerci se è stato modificato rispetto il nuovo default.

Se dobbiamo verificare rapidamente i numeri di versione di molti file si può usare il seguente comando PowerShell

Get-ChildItem \\path_to_build_outputs\*.dll | foreach { $_.VersionInfo }

Infine il

Salute a tutti e alla prossima,

Giulio

Sure, you could have multiple environments each with a single but different client, but this will require much more resources; the environment has already three servers: domain controller, SQL Server and a Web server. Two environments needs 2*(3+1)=8 VMs, while collapsing in one you have 3+2=5 VMs.

You are using the end-to-end workflow, i.e. LabDefaultTemplate.xaml, to deploy the application and test it. The template wizard has two combo boxes: one for Test Configuration and one for the Test Settings.

So you define a test setting, using the proposed defaults.

But then you realize that both client VMs are in the Web Client role: tests will be distributed among them!

The solution is to:

• using different roles for the two clients
• create different Test Configurations for each client role

As you see below the role are editable

In my case I gave distinct names to the client VMs, say “Web Client XP” and “Web Client 7”; then defined two Test Settings: in each setting, I selected a distinct VM where to run the test (see below picture).

Finally, I define two builds based on the E2E template, each pointing to the proper (automated) test settings, and linked to the matching Test Configuration (see below).

So far so good, but having two build definitions is a bit inelegant. Later I found this blog post https://blogs.msdn.com/b/lab_management/archive/2011/05/26/configuration-matrix-testing-using-visual-studio-lab-management.aspx, that suggest how to add a second test run with different settings to the E2E workflow.

Happy building!

The Rangers Build Customization Guide is public on Codeplex and I am happy this is over… for while. Willy and Bijan are very demanding on ALM Rangers and already started on new projects and team.

I do not like repeating, so get the details from Willy’s blog.

If you don’t like it, have suggestions on the existing content, or think that we should invest in some untouched scenario, just shout: this is just the first edition.

Remember also: this work is done by volunteers on their extra time, so be patient and constructive on your comments.

The other day a question came from a colleague, that sounded like this.

My client has been using TFS for many years now and has a production deployment consisting of about 4 TFS 2008 servers containing about 50, 50, 25 & 25 team projects respectively.

Now they are in the process of migrating to TFS 2010 and they want to understand the options: their eventual goal is to move all the team projects to one very large TFS 2010 instance.

This is my response, as it could be useful to others.

In your customer scenario you have to choose between:

• A full-fidelity migration, mapping each TFS instance to a separate collection, or
• A loose data migration, moving data around.

In the first case, you use the upgrade wizard for the first server, then repeat the process using tfsconfig import.

In the latter case, you use the Tfs Integration Platform. Don’t be distracted by finding it on Codeplex: there is also a supported version in the VS Gallery and is routinely used internally at Microsoft.

In my opinion, you should ask the customer what they really want to achieve and when. Here some possible approaches to the problem:

• Piecemeal: you create a new instance of TFS 2010 and move a team (create an new Team Project and check-in the code) at their ease leaving history on the old server
  Pros: easy to implement; zero downtime
  Cons: slow and need more resources
• One Team Project Collection for all: use integration tools
  Pros: simplified view and management; less resources
  Cons: they lose some history; more work to implement
• Multiple Team Project Collections, one from each old server, plus a “consolidated wharehouse” Team Project Collection: an hybrid solution that uses the out-of-the-box upgrade/import feature, with the integration tool you consolidate the data in a new Team Project Collection for reporting and other consolidated views
  Pros: full-fidelity
  Cons: need more resources, e.g. one Controller per Team Project Collection

You can also think of a mix of these strategies, selecting the best approach for different teams.

A very welcome news, today. The BizTalk team released to public an hotfix to let BizTalk projects (.btproj) to compile successfully under TeamBuild 2010 (https://support.microsoft.com/kb/2406405).

I discovered the issues myself and worked with the team to find some workaround. I am already using this fix in our project and I have been able to remove my own hacks.

You can find more details on bharry's blog.

Beware: this patch allows Team Foundation Server 2010 to build BizTalk 2009 projects. For developing you still need to use Visual Studio 2008 SP1 plus the Update for Microsoft Visual Studio 2010 Lab Management.

This tool takes a number of Excel files, in the format required by XmlPreprocess / EnvironmentSettingsExporter, and outputs a single Excel file in the same format by removing duplicates, stopping in case of clashes, etc.

The idea is to leave each BizTalk application independent, with all the BTDF stuff, but also handle a single Excel file to operation; this also avoid contemption of having a single settings file for all application up front.

The resulting file will have a column for each distinct environment name and a row for each distinct setting. Here you have an example of two input files.

The result of the merge has 6 rows and 5 columns (not counting the one with settings’ names).

Feedback is more than welcome, and apologize for bugs and lack of documentation.

UPDATE: This tool has been merged in EnvironmentSettingsExporter: it is not part of an official release, but you may download the code, compile and use it. Beware that the new version has a different syntax to support the expanded functionality.

It is both a tool and a framework, based on Powershell v2, aimed at simplifying deployment of applications, especially BizTalk-based. It stands on the shoulders of giants as it extends the Deployment Framework for BizTalk: this latter is focused on deploying a single BizTalk application, while Sprinkler manages multiple BizTalk applications and multiple servers.

Notable features are:

• Parallelization of execution — the tool must be run on all servers of the farm and will operate concurrently as much as possible, reducing deployment time window;
• Can be run from a central location by leveraging Powershell v2 remoting;
• Script based — requires Powershell v2, no additional component to install on any server; you can Zip everything and send it to a different site;
• Flexible layout — keep all the files in a single share or spread them in different locations to keep sensitive information in a safe place or in a read-only folder;
• Simple configuration — all parameters for execution are contained in just two files;
• Interactive and unattended mode — an menu driven wizard helps choosing the script to run and its parameters;
• Complete and centralized logging in plain text files;
• Can execute sections of code in 32-bits for compatibility;
• Rich library for operating BizTalk — stopping host instances, setting host adapters, starting and stopping applications in order, BRE rules managing;
• Add new scripts and functions that leverage all above features.

Feedback is more than welcome, and apologize for bugs and lack of documentation.