Demonstra Passo a passo: Personalizando Team Foundation compilação com uma tarefa personalizada
[Observação: Este tópico é pré-versão documentação e está sujeitas a alterações em versões futuras. Tópicos em branco são incluídos sistema autônomo espaços reservados.]
Você pode estender Team Foundation Build Criando suas próprias tarefas personalizadas e executá-los durante uma compilação. Este tópico explica as etapas necessárias para estender uma definição de compilação com uma tarefa personalizada.
Permissões necessárias
Para concluir esta explicação passo a passo, você deve ter o Administrar uma compilação permissão definido como Permitir.Para obter mais informações, consulte Team Foundation servidor Permissões.
Criando uma definição de compilação
Use o Criar definição caixa de diálogo para criar uma nova definição de compilação.Você pode compartilhar um arquivo TFSBuild.proj existente ou criar um novo com o Assistente para criação de arquivo de projeto MSBuild.Você edição o arquivo TFSBuild.proj personalizar cada definição de compilação que está associada ele.Para obter mais informações sobre como criar definições de compilação, consulte Como: Criar uma definição de compilação.
Criar tarefas personalizadas
Tarefas fornecem o código que executa durante o processo de compilação.Essas tarefas estão contidas em Target elementos de MSBuild arquivos de projeto. MSBuild é o mecanismo por trás Team Foundation Build. Tarefas personalizadas devem estar em um formato que MSBuild entende. Cada tarefa deve ser implementado sistema autônomo uma classe .NET que implementa o ITask interface, que é definido no assembly Microsoft.compilação.estrutura.dll.
Há duas abordagens que você pode usar durante a implementação de uma tarefa:
Implementar o ITask interface diretamente.
Derivar a classe de classe auxiliar, Task, que é definido no assembly Microsoft.compilação.Utilities.dll. Task implementa ITask e fornece implementações padrão de alguns ITask membros.
As duas abordagens, você deve adicionar à sua classe um método chamado Execute, que é o método chamado quando a tarefa é executada. Esse método não usa nenhum parâmetro e retorna um Boolean valor: true Se a tarefa for bem-sucedido ou false em caso de falha. O exemplo a seguir mostra uma tarefa que não executa nenhuma ação e retorna true.
using System;
using Microsoft.Build.Framework;
using Microsoft.Build.Utilities;
namespace MyTasks
{
public class SimpleTask : Task
{
public override bool Execute()
{
return true;
}
}
}
Tarefas também podem aceitar parâmetros, disparar eventos e log de saída.Para obter mais informações, consulte Tarefas do MSBuild e Visão geral do MSBuild.
Fazendo check-out TFSBuild.proj
Depois que você tenha escrito a tarefa, você precisará registrá-lo e chamá-lo para fora em um dos destinos para que seu código da tarefa é executada no ponto desejado o processo de compilação.Se você usou o Assistente para criação de arquivo de projeto MSBuild para criar um MSBuild arquivo de projeto e aceita o localização padrão no controle de fonte, seu TFSBuild.proj arquivo está localizado na pasta $ /MyTeamProject/TeamBuildTypes/ MyBuildName in your Visual Studio Team System controle do código-fonte. Nesse cenário, MyTeamProject é o nome do seu projeto da equipe e é o nó raiz de todas as fontes do projeto da equipe e MyBuildName é o nome que você deu para sua definição de compilação para o qual você originalmente criado o arquivo TFSBuild.proj.
Para determinar o controle do código-fonte local do arquivo TFSBuild.proj, selecionar a definição de compilação no Compilações pasta Team Explorer, clicar com o botão direito do mouse nele e, em seguida, clique em edição.Do arquivo TFSBuild.proj controle do código-fonte local é exibido sobre o Arquivo de projeto painel do definição de compilação da caixa de diálogo.
.gif "Observação") Observação: |
|---|
Não edite o arquivo Microsoft.TeamFoundation.compilação.targets porque as personalizações irão aplicar a todas as compilações nesse computador. |
Para obter informações sobre o check-out de arquivos, consulte Trabalhando com Team Foundation version Controlar.
Registrando sua tarefa
Depois de criar a tarefa, você deve registrá-lo, especificando a tarefa em um UsingTask elemento do arquivo TFSBuild.proj. The UsingTask elemento mapeia a tarefa para o assembly que contém a implementação da tarefa. Para obter mais informações, consulte Elemento UsingTask (MSBuild).
Para registrar uma tarefa personalizada
em aberto arquivo TFSBuild.proj.
Adicionar um UsingTask elemento para o arquivo e especifique os detalhes da tarefa.
Por exemplo:
<UsingTask TaskName="MyTasks.SimpleTask" AssemblyName="MyAssembly.Build.Tasks"/>-ou-
<UsingTask TaskName="MyTasks.SimpleTask" AssemblyFile="MyAssembly.Build.Tasks.dll"/>-ou-
<UsingTask TaskName="MyTasks.SimpleTask" AssemblyFile="c:\somediskpath\MyAssembly.Build.Tasks.dll"/>Salve o arquivo.
Executando tarefa personalizada
Agora que você tiver criado e registrado sua tarefa, você deve especificar o ponto no processo de compilação que você deseja executar a tarefa.
Para executar uma tarefa
Decida onde no processo de compilação que deseja executar suas tarefas personalizado.
Para obter mais informações sobre onde você pode estender o processo de compilação, consulte Noções básicas sobre Arquivos de Configuração de Compilação do Team Foundation.
Abra TFSBuild.proj e adicione o Target elemento que você escolheu acima.
Adicione o elemento de tarefa para executar a tarefa dentro de Target elemento.
Por exemplo, o seguinte XML TFSBuild.proj executa o SimpleTask tarefa na BeforeGet destino, que é executado imediatamente antes de Get destino.
<Target Name="BeforeGet"> <SimpleTask /> </Target>Salve o arquivo.
Fazendo check-in de arquivos
Você deve fazer check-in do arquivo TFSBuild.proj para que as alterações tenham efeito.Team Foundation Build Copia o arquivo controle do código-fonte logon no computador de construção, assim, qualquer alterações feitas na cópia local no seu computador não afetarão a compilação. Para obter mais informações sobre a verificação de arquivos em controle do código-fonte, consulte Como: Alterações pendentes Fazer Marcar-in.
Se você precisar de Team Foundation Build Para copiar a tarefa DLL para o computador de construção, você deve adicionar a tarefa DLL para controle do código-fonte sob o nó do projeto da equipe.
Tarefa de exemplo
Este exemplo cria uma tarefa personalizada que estende a definição de compilação ou definições que estão associadas ao arquivo TFSBuild.proj fazendo o dimensionar dos arquivos produzidos pela compilação.O exemplo contém duas partes:
O código da tarefa.
O arquivo TFSBuild.proj.
As informações registradas desta tarefa podem ser vistas no arquivo de log de compilação, buildlog.txt, que está localizado na pasta build soltar.O log de compilação contém informações semelhantes às seguintes:
O dimensionar total é de 9.216 bytes em d:\BuildDir\MyTeamProj\MyBuildType\sources\Dir \Binaries\versão
Código da tarefa translation from VPE for Csharp
O exemplo a seguir contém o código que calcula o dimensionar total binário adicionando o dimensionar dos arquivos na pasta de binários.
| Observação: |
|---|
Todos os binários gerados durante uma compilação estão localizados na pasta binários na pasta build diretório no agente de compilação. |
Para essa tarefa a serem incluídos em uma compilação, a DLL compilada deve ser verificada em controle do código-fonte sob a pasta de projeto da equipe.Isso garante que o arquivo será copiado para o agente de compilação durante uma compilação.
O código a seguir calcula o dimensionar dos binários presentes na pasta do diretório de compilação de binários.A propriedade da solução raiz é passada para esta tarefa, a Team Foundation Build script.
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;
}
}
Arquivo TFSBuild.proj
Depois que a tarefa for compilada e verificada no controle do código-fonte, ele deve ser chamado a partir de arquivo TFSBuild.proj.Neste exemplo, a tarefa deve ser chamada depois que os arquivos foram compilados e todos os binários foram copiados para o diretório de binários.Portanto, a tarefa deverá ser executada no BeforeDropBuild destino. Para obter mais informações sobre os destinos extensíveis TFSBuild.proj, consulte Noções básicas sobre Arquivos de Configuração de Compilação do Team Foundation.
O exemplo a seguir contém o código no arquivo TFSBuild.proj modificado.O exemplo XML quase inteiramente é gerado pelo Assistente para criação de arquivo de projeto MSBuild, com exceção do UsingTask elemento e o Target elemento localizado no participante do arquivo.
<?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>