Procedura dettagliata: personalizzazione di Team Foundation Build con un'attività personalizzata
Aggiornamento: novembre 2007
È possibile estendere Team Foundation Build creando attività personalizzate ed eseguendole durante una compilazione. In questo argomento vengono illustrate le operazioni necessarie per estendere una definizione di compilazione con un'attività personalizzata.
Autorizzazioni necessarie
Per completare questa procedura dettagliata, è necessario disporre dell'autorizzazione Amministra compilazione impostata su Consenti. Per ulteriori informazioni, vedere Autorizzazioni per Team Foundation Server.
Creazione di una definizione di compilazione.
Utilizzare la finestra di dialogo Definizione di compilazione per creare una nuova definizione di compilazione. È possibile condividere un file TFSBuild.proj esistente, o crearne uno nuovo tramite la Creazione guidata file progetto MSBuild. Modificare il file TFSBuild.proj per personalizzare ogni definizione di compilazione associata. Per ulteriori informazioni sulla creazione delle definizioni di compilazione, vedere Procedura: creare una definizione di compilazione.
Creazione di attività personalizzate
Le attività forniscono il codice da eseguire durante il processo di generazione. Queste attività sono contenute negli elementi Target dei file di progetto MSBuild. MSBuild è il motore di Team Foundation Build. Le attività personalizzate devono presentare un formato comprensibile da MSBuild. Ogni attività deve essere implementata come classe .NET che implementa l'interfaccia ITask, definita nell'assembly Microsoft.Build.Framework.dll.
Per implementare un'attività, è possibile utilizzare due approcci diversi:
Implementare direttamente l'interfaccia ITask.
Derivare la classe dalla classe di supporto, Task, definita nell'assembly Microsoft.Build.Utilities.dll. Task implementa ITask e fornisce implementazioni predefinite di alcuni membri di ITask.
In entrambi i casi è necessario aggiungere alla classe un metodo denominato Execute, ossia il metodo che viene richiamato quando viene eseguita l'attività. Questo metodo non accetta alcun parametro e restituisce un valore Boolean: true se l'attività ha esito positivo oppure false se ha esito negativo. L'esempio seguente mostra un'attività che non esegue alcuna azione e restituisce true.
using System;
using Microsoft.Build.Framework;
using Microsoft.Build.Utilities;
namespace MyTasks
{
public class SimpleTask : Task
{
public override bool Execute()
{
return true;
}
}
}
Le attività possono inoltre accettare parametri, generare eventi e registrare output. Per ulteriori informazioni, vedere Attività di MSBuild e Cenni preliminari su MSBuild.
Estrazione di TFSBuild.proj
Una volta definita l'attività, è necessario registrarla e includerla in uno degli elementi target affinché il relativo codice venga eseguito al momento desiderato nel processo di generazione. Se per creare un file di progetto MSBuild è stata utilizzata la Creazione guidata file progetto MSBuild ed è stato accettato il percorso predefinito nel controllo del codice sorgente, il file TFSBuild.proj sarà incluso nella cartella $/ProgettoTeam/TipiCompilazioneTeam/NomeCommpilazione nel controllo del codice sorgente di Visual Studio Team System. In questo scenario ProgettoTeam è il nome del progetto Team e il nodo radice di tutte le relative origini mentre NomeCompilazione è il nome assegnato alla definizione di compilazione per cui è stato creato originariamente il file TFSBuild.proj.
Per determinare il percorso di controllo del codice sorgente del file TFSBuild.proj, selezionare la definizione di compilazione nella cartella Builds in Team Explorer, fare clic con il pulsante destro del mouse su di essa, quindi scegliere Modifica. Il percorso del controllo del codice sorgente relativo al file TFSBuild.proj viene visualizzato nel riquadro File di progetto della finestra di dialogo Definizione di compilazione.
.gif "Nota") Nota: |
|---|
Non modificare il file Microsoft.TeamFoundation.Build.targets in quanto le personalizzazioni vengono applicate a tutte le generazioni sul computer. |
Per ulteriori informazioni sull'estrazione dei file, vedere Utilizzo del controllo della versione di Team Foundation.
Registrazione dell'attività
Dopo avere creato l'attività, è necessario registrarla includendola in un elemento UsingTask del file TFSBuild.proj. L'elemento UsingTask associa l'attività all'assembly che ne contiene l'implementazione. Per ulteriori informazioni, vedere Elemento UsingTask (MSBuild).
Per registrare un'attività personalizzata
Aprire il file TFSBuild.proj.
Aggiungere un elemento UsingTask al file e specificare i dettagli dell'attività.
Ad esempio:
<UsingTask TaskName="MyTasks.SimpleTask" AssemblyName="MyAssembly.Build.Tasks"/>-oppure-
<UsingTask TaskName="MyTasks.SimpleTask" AssemblyFile="MyAssembly.Build.Tasks.dll"/>-oppure-
<UsingTask TaskName="MyTasks.SimpleTask" AssemblyFile="c:\somediskpath\MyAssembly.Build.Tasks.dll"/>Salvare il file.
Esecuzione dell'attività personalizzata
Una volta creata e registrata l'attività, è necessario specificare in quale punto del processo di generazione si desidera eseguirla.
Per eseguire un'attività
Determinare in quale punto del processo di generazione si desidera eseguire l'attività personalizzata.
Per ulteriori informazioni su dove è possibile estendere il processo di generazione, vedere Informazioni sui file di configurazione di Team Foundation Build.
Aprire il file TFSBuild.proj e aggiungere l'elemento Target selezionato in precedenza.
Aggiungere l'elemento per eseguire l'attività all'interno dell'elemento Target.
Ad esempio, il seguente codice XML in TFSBuild.proj esegue l'attività SimpleTask nella destinazione BeforeGet, che viene eseguita subito prima della destinazione Get.
<Target Name="BeforeGet"> <SimpleTask /> </Target>Salvare il file.
Archiviazione dei file
Per rendere effettive le modifiche, è necessario archiviare il file TFSBuild.proj. In Team Foundation Build questo file viene copiato dal controllo del codice sorgente sul computer di compilazione in modo che tutte le eventuali modifiche apportate alla copia locale sul computer non verranno applicate alla compilazione. Per ulteriori informazioni sull'archiviazione dei file nel controllo del codice sorgente, vedere Procedura: archiviare le modifiche in sospeso.
Affinché Team Foundation Build copi la DLL dell'attività sul computer di compilazione, è necessario aggiungere questa DLL nel controllo del codice sorgente sotto al nodo del progetto Team.
Attività di esempio
In questo esempio viene creata un'attività personalizzata che estende la definizione o le definizioni di compilazione associate al file TFSBuild.proj registrando la dimensione dei file generati dalla compilazione. Questo esempio contiene due parti:
Il codice dell'attività.
File TFSBuild.proj.
È possibile visualizzare le informazioni registrate da questa attività nel file di log di compilazione Buildlog.txt situato nella cartella di destinazione della compilazione. Il log di generazione contiene informazioni simili a quelle riportate di seguito:
La dimensione totale è 9.216 byte in d:\BuildDir\MyTeamProj\MyBuildType\sources\..\Binaries\Release dir
Codice C# dell'attività
Il seguente esempio contiene il codice che calcola la dimensione binaria totale sommando le dimensioni dei file nella cartella dei file binari.
| Nota: |
|---|
Tutti i file binari generati durante una compilazione si trovano nella sottocartella Binaries della cartella della directory di compilazione sull’agente di compilazione. |
Per includere questa attività in una generazione, è necessario archiviare la DLL compilata nel controllo del codice sorgente nella cartella del progetto Team. In questo modo il file verrà copiato nell'agente di compilazione durante un'operazione di compilazione.
Nel codice seguente vengono calcolate le dimensioni dei file binari presenti nella cartella Binaries della directory di compilazione. La proprietà della directory principale della soluzione viene passata all'attività specificata mediante lo script di Team Foundation Build.
using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.Build.Framework;
using Microsoft.Build.Utilities;
using System.Diagnostics;
using System.IO;
namespace BuildTask
{
public class BinSize : Task
{
private string sourceDir;
[Required]
public string SourceDir
{
get { return sourceDir; }
set { sourceDir = value; }
}
public override bool Execute()
{
string szDir = sourceDir + "\\..\\Binaries";
ProcessDirectory(szDir);
return true;
}
private void ProcessDirectory(string targetDirectory)
{
// Process the list of files found in the directory.
string[] fileEntries = Directory.GetFiles(targetDirectory, "*.*");
if (fileEntries.Length > 0)
{
dwSize = 0;
szCurrDir = targetDirectory;
foreach (string fileName in fileEntries)
ProcessFile(fileName);
////////////////////////////////////////////////////////////////////////
// This log message would just print out a line in the build log file.
// You need to add code to do what you need to do with this data. e.g.
// publishing it into the warehouse for reporting.
///////////////////////////////////////////////////////////////////////
Log.LogMessage("The total size of is {0} bytes in {1} dir",
dwSize, targetDirectory);
}
// Recurse into subdirectories of this directory.
string[] subdirectoryEntries = Directory.GetDirectories(targetDirectory);
foreach (string subdirectory in subdirectoryEntries)
ProcessDirectory(subdirectory);
}
private void ProcessFile(string path)
{
FileInfo fi = new FileInfo(path);
dwSize = dwSize + fi.Length;
}
private long dwSize;
private string szCurrDir;
}
}
File TFSBuild.proj
Una volta compilata e archiviata l'attività nel controllo del codice sorgente, è necessario chiamarla dal file TFSBuild.proj. Poiché in questo esempio l'attività deve essere chiamata dopo che i file sono stati compilati e tutti i file binari sono stati copiati nella rispettiva directory, eseguire l'attività nel target BeforeDropBuild. Per ulteriori informazioni sulle destinazioni estendibili in TFSBuild.proj, vedere Informazioni sui file di configurazione di Team Foundation Build.
Nell'esempio riportato di seguito è incluso il codice del file TFSBuild.proj modificato. Il codice XML dell'esempio viene generato quasi interamente dalla Creazione guidata file di progetto MSBuild, a eccezione degli elementi UsingTask e Target situati alla fine del file.
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="DesktopBuild" xmlns="https://schemas.microsoft.com/developer/msbuild/2003">
<!-- TO EDIT BUILD TYPE DEFINITION
TODO: Update all of the comments in this file!
To edit the build type, you will need to edit this file which was generated
by the Create New Build Type wizard. This file is under source control and
needs to be checked out before making any changes.
The file is available at:
$/{TeamProjectName}/TeamBuildTypes/{BuildTypeName}
where you will need to replace TeamProjectName and BuildTypeName with your
Team Project and Build Type name that you created
Checkout the file
1. Open Source Control Explorer by selecting View -> Other Windows -> Source Control Explorer
2. Ensure that your current workspace has a mapping for the $/{TeamProjectName}/TeamBuildTypes folder and
that you have done a "Get Latest Version" on that folder
3. Browse through the folders to {TeamProjectName}->TeamBuildTypes->{BuildTypeName} folder
4. From the list of files available in this folder, right click on TfsBuild.Proj. Select 'Check Out For Edit...'
Make the required changes to the file and save
Checkin the file
1. Right click on the TfsBuild.Proj file selected in Step 3 above and select 'Checkin Pending Changes'
2. Use the pending checkin dialog to save your changes to the source control
Once the file is checked in with the modifications, all future builds using
this build type will use the modified settings
-->
<!-- Do not edit this -->
<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets" />
<ProjectExtensions>
<!-- Team Foundation Build Version - DO NOT CHANGE -->
<ProjectFileVersion>2</ProjectFileVersion>
<!-- DESCRIPTION
TODO: Obsolete.
-->
<Description>this one automatically builds on check in</Description>
<!-- BUILD MACHINE
TODO: Obsolete.
-->
<BuildMachine>ahetod-test2</BuildMachine>
</ProjectExtensions>
<PropertyGroup>
<!-- Properties set by the build type creation wizard -->
<!-- TEAM PROJECT
TODO: Obsolete.
-->
<TeamProject>TeamProjectName</TeamProject>
<!-- BUILD DIRECTORY
TODO: Obsolete.
-->
<BuildDirectoryPath>C:\Documents and Settings\user\Local Settings\Temp\1\TeamProjectName\BuildDefinitionName</BuildDirectoryPath>
<!-- DROP LOCATION
TODO: Obsolete.
-->
<DropLocation>\\UNKNOWN\drops</DropLocation>
<!-- TESTING
Set this flag to enable/disable running tests as a post build step.
-->
<RunTest>false</RunTest>
<!-- CODE ANALYSIS
To change CodeAnalysis behavior edit this value. Valid values for this
can be Default,Always or Never.
Default - To perform code analysis as per the individual project settings
Always - To always perform code analysis irrespective of project settings
Never - To never perform code analysis irrespective of project settings
-->
<RunCodeAnalysis>Never</RunCodeAnalysis>
<!-- Additional Properties -->
<!-- WorkItemType
The type of the work item created on a build break - if empty, "Bug" will be used
-->
<WorkItemType Condition=" '$(WorkItemType)'=='' "></WorkItemType>
<!-- WorkItemFieldValues
Add/edit key value pairs to set values for fields in the work item created
during the build process. Please make sure the field names are valid
for the work item type being used.
-->
<WorkItemFieldValues>Symptom=build break;Steps To Reproduce=Start the build using Team Build</WorkItemFieldValues>
<!-- WorkItemTitle
Title for the work item created on build failure
-->
<WorkItemTitle>Build failure in build:</WorkItemTitle>
<!-- DescriptionText
Description for the work item created on a build failure
-->
<DescriptionText>This work item was created by Team Build on a build failure.</DescriptionText>
<!-- BuildLogText
Additional text for the work item create on a build failure.
-->
<BuildlogText>The build log file is at:</BuildlogText>
<!-- ErrorWarningLogText
Additional text for the work item create on a build failure
-->
<ErrorWarningLogText>The errors/warnings log file is at:</ErrorWarningLogText>
<!-- UpdateAssociatedWorkItems
Set this flag to enable/disable updating associated workitems on a successful build
-->
<UpdateAssociatedWorkItems>true</UpdateAssociatedWorkItems>
<!-- AdditionalVCOverrides
Additional text for the VCOverrides file generated for VC++ projects
-->
<AdditionalVCOverrides></AdditionalVCOverrides>
<!-- CustomPropertiesForClean
Custom properties to pass to the MSBuild task while calling the "Clean" target for all solutions.
The format should be: PropertyName1=value1;PropertyName2=value2;...
-->
<CustomPropertiesForClean></CustomPropertiesForClean>
<!-- CustomPropertiesForBuild
Custom properties to pass to the MSBuild task while calling the default targets for all solutions.
The format should be: PropertyName1=value1;PropertyName2=value2;... To pass custom properties to
individual solutions, use the Properties metadata item of the SolutionToBuild ItemGroup.
-->
<CustomPropertiesForBuild></CustomPropertiesForBuild>
</PropertyGroup>
<ItemGroup>
<!-- SOLUTIONS
The paths of the solutions to build. To add/delete solutions, edit this
ItemGroup. For example, to add a solution MySolution.sln, add the following line:
<SolutionToBuild Include="$(BuildProjectFolderPath)\path\MySolution.sln" />
To change the order in which the solutions are built, modify the order in
which the solutions appear below.
To call a target (or targets) other than the default, add a metadata item named
Targets. To pass custom properties to the solution, add a metadata item named
Properties. For example, to call the targets MyCustomTarget1 and MyCustomTarget2,
passing in properties Property1 and Property2, add the following:
<SolutionToBuild Include="$(BuildProjectFolderPath)\path\MySolution.sln">
<Targets>MyCustomTarget1;MyCustomTarget2</Targets>
<Properties>Property1=Value1;PropertyTwo=Value2</Properties>
</SolutionToBuild>
-->
<SolutionToBuild Include="$(BuildProjectFolderPath)/../../SimpleAppToBuild/SimpleAppToBuild.sln">
<Targets></Targets>
<Properties></Properties>
</SolutionToBuild>
</ItemGroup>
<ItemGroup>
<!-- CONFIGURATIONS
The list of configurations to build. To add/delete configurations, edit
this value. For example, to add a new configuration, add the following lines:
<ConfigurationToBuild Include="Debug|x86">
<FlavorToBuild>Debug</FlavorToBuild>
<PlatformToBuild>x86</PlatformToBuild>
</ConfigurationToBuild>
The Include attribute value should be unique for each ConfigurationToBuild node.
-->
<ConfigurationToBuild Include="Release|Any CPU">
<FlavorToBuild>Release</FlavorToBuild>
<PlatformToBuild>Any CPU</PlatformToBuild>
</ConfigurationToBuild>
</ItemGroup>
<ItemGroup>
<!-- TEST ARGUMENTS
If the RunTest property is set to true then the following test arguments will be used to run
tests. Tests can be run by specifying one or more test lists and/or one or more test containers.
To run tests using test lists, add MetaDataFile items and associated TestLists here:
<MetaDataFile Include="$(SolutionRoot)\HelloWorld\HelloWorld.vsmdi">
<TestList>BVT1;BVT2</TestList>
</MetaDataFile>
To run tests using test containers, add TestContainer items here:
<TestContainer Include="$(OutDir)\HelloWorldTests.dll" />
<TestContainer Include="$(SolutionRoot)\TestProject\WebTest1.webtest" />
<TestContainer Include="$(SolutionRoot)\TestProject\LoadTest1.loadtest" />
-->
</ItemGroup>
<ItemGroup>
<!-- ADDITIONAL REFERENCE PATH
The list of additional reference paths to use while resolving references.
For example:
<AdditionalReferencePath Include="C:\MyFolder\" />
<AdditionalReferencePath Include="C:\MyFolder2\" />
-->
</ItemGroup>
<UsingTask TaskName="BuildTask.BinSize" AssemblyFile="$(SolutionRoot)\tools\BuildTask.dll" /> <Target Name="BeforeDropBuild"> <BinSize SourceDir="$(SolutionRoot)" /> </Target>
</Project>
Vedere anche
Attività
Procedura: scrivere un'attività