I'm in the midst of doing a test upgrade from TFS2010 to TFS2012. They're using the Upgrade Template to run an extensive set of custom MSBuild tasks to automate their build and deployment. The MSBuild projects were originally created for TFS2005, and were upgraded directly to TFS2010 at some point. The solutions they're building are mostly targeted at .NET 2.0, and they're still using VS2005 for most development.
So far, I've installed VS2005, VS2010, and TFS2012 with Update 1 (in that order), and upgraded their TFS2010 databases to TFS2012. The build controller lives on the same machine as the app tier and database, just because this is a "proof of concept" upgrade to identify any issues that will need to be addressed with the build process prior to the real upgrade.
When I run any of their MSBuild-based builds, I get the following error:
C:\Builds\18\Web\ES-INTEGRATION-WebTest\BuildType\TFSBuild.proj (75):
An extension of type
'Microsoft.TeamFoundation.Build.Client.IBuildDetail' must be
configured in order to run this workflow.
C:\Builds\18\Web\ES-INTEGRATION-WebTest\BuildType\TFSBuild.proj (75):
The "Get" task failed unexpectedly.
System.Activities.ValidationException: An extension of type
'Microsoft.TeamFoundation.Build.Client.IBuildDetail' must be
configured in order to run this workflow.
at
System.Activities.Hosting.WorkflowInstanceExtensionCollection..ctor(Activity
workflowDefinition, WorkflowInstanceExtensionManager extensionManager)
at
System.Activities.Hosting.WorkflowInstanceExtensionManager.CreateInstanceExtensions(Activity
workflowDefinition, WorkflowInstanceExtensionManager extensionManager)
at
System.Activities.Hosting.WorkflowInstance.RegisterExtensionManager(WorkflowInstanceExtensionManager
extensionManager)
at System.Activities.WorkflowApplication.EnsureInitialized()
at
System.Activities.WorkflowApplication.RunInstance(WorkflowApplication
instance)
at System.Activities.WorkflowApplication.Invoke(Activity activity,
IDictionary`2 inputs, WorkflowInstanceExtensionManager extensions,
TimeSpan timeout)
at System.Activities.WorkflowInvoker.Invoke(Activity workflow,
IDictionary`2 inputs, TimeSpan timeout,
WorkflowInstanceExtensionManager extensions)
at
Microsoft.TeamFoundation.Build.Tasks.WorkflowTask.ExecuteInternal()
at Microsoft.TeamFoundation.Build.Tasks.Task.Execute()
at
Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
at
Microsoft.Build.BackEnd.TaskBuilder.d__20.MoveNext()
I've gone through and pared the build down to a very small case that reproduces the issue. The complete .proj file is as follows:
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="DesktopBuild" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="4.0">
<!-- Do not edit this -->
<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets" />
<ProjectExtensions>
<!-- DESCRIPTION
The description is associated with a build type. Edit the value for making changes.
-->
<Description>Builds and Deploys the BE site to the integration environment</Description>
<!-- BUILD MACHINE
Name of the machine which will be used to build the solutions selected.
-->
<BuildMachine>[redacted]</BuildMachine>
</ProjectExtensions>
<PropertyGroup>
<!-- TEAM PROJECT
The team project which will be built using this build type.
-->
<TeamProject>Web</TeamProject>
<!-- BUILD DIRECTORY
The directory on the build machine that will be used to build the
selected solutions. The directory must be a local path on the build
machine (e.g. c:\build).
-->
<BuildDirectoryPath>c:\build</BuildDirectoryPath>
<!-- DROP LOCATION
The location to drop (copy) the built binaries and the log files after
the build is complete. This location has to be a valid UNC path of the
form \\Server\Share. The build machine service account and application
tier account need to have read write permission on this share.
-->
<DropLocation>\\[redacted]\BuildDrop</DropLocation>
<!-- TESTING
Set this flag to enable/disable running tests as a post build step.
-->
<RunTest>True</RunTest>
<!-- 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>
<!-- 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>Default</RunCodeAnalysis>
<!-- UPDATE ASSOCIATED WORK ITEMS
Set this flag to enable/disable updating associated workitems on a successful build
-->
<UpdateAssociatedWorkItems>false</UpdateAssociatedWorkItems>
<!-- Title for the work item created on build failure -->
<WorkItemTitle>Build failure in build:</WorkItemTitle>
<!-- Description for the work item created on build failure -->
<DescriptionText>This work item was created by Team Build on a build failure.</DescriptionText>
<!-- Text pointing to log file location on build failure -->
<BuildlogText>The build log file is at:</BuildlogText>
<!-- Text pointing to error/warnings file location on build failure -->
<ErrorWarningLogText>The errors/warnings log file is at:</ErrorWarningLogText>
</PropertyGroup>
<PropertyGroup>
<SourceBranchPath>Main</SourceBranchPath>
</PropertyGroup>
<!-- Does some basic validation of the environment before the build starts -->
<Target Name="PreBuildValidations" >
<Get FileSpec="$/Web/$(SourceBranchPath)/BuildFiles/Tools/PSExec.exe" Workspace="$(WorkspaceName)" Recursive="false" Force="true" TeamFoundationServerUrl="$(TeamFoundationServerUrl)"/>
</Target>
<Target Name="BeforeGet">
<CallTarget Targets="PreBuildValidations" />
</Target>
</Project>
I figured it out. Apparently, the BuildUri parameter is required for the Get task. I added BuildUri="$(BuildURI)" and all is well.
Your build is failing on the "Get Task" in your msbuild script. You are only pulling down one file which is an .exe file in the BeforeGet target. In order to build a project you need a project file.
It looks like the error may be because you missing a parameter or passing in an invalid parameter in the Get task.
Why the need for a prebuildvalidation step when the build can just pull the file down from the build definition workspace?
Related
I am learning Jenkins an I am able to build a project using Ant. I can't understand one thing, when I build a project using Netbeans and Ant I get the .ear in a dist fodler but one I build the same project uisng Jenkins and Ant I dont get the .ear (no dist folder too!).
To build a project (entreprise application built with Ant) using Jenkins I followed the following steps:
I have created a new job in jenkins (freestyle job)
In the Build section I added a new build setup (Invoke Ant)
In the Invoke Ant section, for Targets I have put compile and for Build File I have put build.xml
Then I copied the content of my project in the created folder by Jenkins in the workspace
Finally I started the build.
How can I generate the .ear of my project using Jenkins + Ant?
Here is the content of my build.xml:
<?xml version="1.0" encoding="UTF-8"?>
<!-- You may freely edit this file. See commented blocks below for -->
<!-- some examples of how to customize the build. -->
<!-- (If you delete it and reopen the project it will be recreated.) -->
<!-- By default, only the Clean and Build commands use this build script. -->
<!-- Commands such as Run, Debug, and Test only use this build script if -->
<!-- the Compile on Save feature is turned off for the project. -->
<!-- You can turn off the Compile on Save (or Deploy on Save) setting -->
<!-- in the project's Project Properties dialog box.-->
<project name="SIFC" default="default" basedir="." xmlns:ear="http://www.netbeans.org/ns/j2ee-earproject/2">
<description>Builds, tests, and runs the project SIFC.</description>
<import file="nbproject/build-impl.xml"/>
<!--
There exist several targets which are by default empty and which can be
used for execution of your tasks. These targets are usually executed
before and after some main targets. They are:
pre-init: called before initialization of project properties
post-init: called after initialization of project properties
pre-compile: called before javac compilation
post-compile: called after javac compilation
pre-dist: called before archive building
post-dist: called after archive building
post-clean: called after cleaning build products
pre-run-deploy: called before deploying
post-run-deploy: called after deploying
Example of pluging an obfuscator after the compilation could look like
<target name="post-compile">
<obfuscate>
<fileset dir="${build.classes.dir}"/>
</obfuscate>
</target>
For list of available properties check the imported
nbproject/build-impl.xml file.
Other way how to customize the build is by overriding existing main targets.
The target of interest are:
do-dist: archive building
run: execution of project
Example of overriding the target for project execution could look like
<target name="run" depends="<PROJNAME>-impl.jar">
<exec dir="bin" executable="launcher.exe">
<arg file="${dist.jar}"/>
</exec>
</target>
Notice that overridden target depends on jar target and not only on
compile target as regular run target does. Again, for list of available
properties which you can use check the target you are overriding in
nbproject/build-impl.xml file.
-->
</project>
I want to set up my VS solution so at the end of the build, the installable files are zipped up for easy distribution. This should work under either a local build, or a TFS build. This is set up as follows:
There is one project (called MyApp.Packaging) which contains no code, just an MSBUILD .targets script
The project has references to all other projects, so builds last (confirmed by looking at the Project Build Order)
The build script contains the following to identify and zip (using MSBUILD Community Tasks' ZIP task) the EXE and DLLs into two different packages (there is other code to pull the version number from a version.txt file using MSBUILD Community Tasks - omitted for clarity)
<!-- Set package name and input/output folders -->
<PropertyGroup>
<PackageName>MyAppService</PackageName>
<BuildTargetFolder>$(TargetDir)</BuildTargetFolder>
<PackageOutputFolder>$(OutDir)</PackageOutputFolder>
</PropertyGroup>
<!-- Set location of files -->
<ItemGroup>
<MyAppBinaries Include="$(BuildTargetFolder)*.exe$(BuildTargetFolder)*.dll;" Exclude="$(BuildTargetFolder)MyApp.Packaging.dll" />
<MyAppOtherFiles Include="$(SolutionDir)MyApp.Packaging\InstallService.bat;$(SolutionDir)MyApp.Packaging\UnInstallService.bat;$(BuildTargetFolder)MyApp.HostService.exe.config" />
<MyAppContracts Include="$(BuildTargetFolder)MyApp.Common.DataContext.dll;$(BuildTargetFolder)MyApp.Common.Shared.dll" />
</ItemGroup>
<!-- After building (in Release mode only), build the installation package -->
<Target Name="AfterBuild">
<CallTarget Targets="BuildPackage" Condition="'$(Configuration)'=='Release'" />
</Target>
<!-- Build the package -->
<Target Name="BuildPackage">
<!-- Package for installing the MyApp Service -->
<Zip Files="#(MyAppBinaries);#(MyAppOtherFiles)" Flatten="True" WorkingDirectory="$(MSBuildProjectDirectory)" ZipFileName="$(PackageOutputFolder)\$(PackageName)_$(Major).$(Minor).$(Revision)_Install.zip" />
<!-- Package for MyApp Contracts -->
<Zip Files="#(MyAppContracts)" Flatten="True" WorkingDirectory="$(MSBuildProjectDirectory)" ZipFileName="$(PackageOutputFolder)\$(PackageName)_MyAppContracts_$(Major).$(Minor).$(Revision)_Install.zip" />
</Target>
The ZIP files are created in the TFS drop location when TFS does the build, or the Packaging project's bin folder for a local build.
The second ZIP (containing 2 DLLs) always gets created OK, under local and TFS build.
The problem is that when TFS does the build, the first ZIP contains no EXE and only 2 of the 23 DLLs (and all 3 of the files identified by MyAppOtherFiles). When the build is done locally (and the the Packaging project's bin folder is emptied first), the first ZIP contains no EXE or DLLs, and only the 2 .bat files identified by MyAppOtherFiles.
If I change BuildTargetFolder from $(TargetDir) to $(OutDir), I get the same result.
The TFS build definition uses an unmodified Default Template.
It is as if when TFS does the build, the Packaging project is the 3rd project to be built, rather than the last, therefore only zipping 2 DLLs. However, the solution checked into TFS is exactly the same as what I build locally, and in that case it seems the script cannot see ANY of the binaries. If the local build is done again (without emptying the Packaging project's bin folder), the ZIPs then contain all the required files, but this is obviously because after the 1st build the bin folder now contains the EXE & all the DLLs.
Its also confusing that under a TFS build the MyApp.HostService.exe.config (which is produced by the build) is zipped, but not the MyApp.HostService.exe. And why is the 2nd ZIP always created OK, when it contains DLLs that are skipped in the 1st ZIP ????? I have tried swapping the order the ZIPs are created, but it makes no difference!
What can I do to ensure that the zipping is always done after all the projects are built, under both local and a TFS build?
Thanks
Make sure you set the packaging project dependency on the solution depend on the other projects this way it will always build the others first, thus leaving you with the packaging last.
We do something similar but we have our tfs build definition setup to build the targets/proj file instead of the sln. In the targets/proj file we have a target that compiles our application and then uses wix to create a msi. In your case, you should create a target that uses the msbuild target to compile your exe project and then call the zip target to compress the output. You can leave the outdir parameter as is our you can set the property so the output goes to a directory of your choosing. Building this easy will work on both the tfs server and locally.
I have found other posts here on StackOverflow that deal with my issue I am experiencing, for example:
MSBuild: Deploying files that are not included in the project as well as Include Files in MSBuild that are not a part of the project
I wanted to share the code that I was able to create after reading these posts and ask for some help as to why it might not be working?
To elaborate on what exactly is not wrong and what I intend to do. I am using Visual Studio 2012, and TFS 2012.
I have a batch file called CreateMyFiles.bat, and what I would like to do is execute this and then take the files it outputs (it outputs them to my Includes/Javascript/Bundled folder) and include them in part of the build in MSBuild (so that they are deployed to the target IIS server).
When I edited my local .csproj in my local Visual Studio and added the code below to the bottom of the file and reloaded, I was able to right click on my web projbect, select 'publish', and then select my local file-based publishing profile which did indeed deploy my files to the correct location. It worked!
I then checked in my code to TFS, and went to 'builds' on TFS, and queued a new build. Sure enough, I was able to see the files output to the same directory on the build server. Now, i'm not 100% sure about MSBuild but I noticed that just like when I hit publish locally, it created a _publishedWebsite folder on the build server as well (a directory above the source). The thing is, within this publishedwebsite folder, my manually created files were not present. Furthermore, going to the target web server after the build was done unfortunately did not have the files I wanted.
So it seems like if I were to manually select publish, the code below works, but if I were to queue a build with TFS, it does not work. Does MSBuild use publish? Could that be the reason it does not work below?
Here is the code I've placed in my .csproj file:
<Target Name="CustomCollectFiles">
<Exec Command="CreateMyFiles.bat" /> <!-- Generate Files -->
<ItemGroup>
<!-- Create an identity called _CustomFiles, and associate it to the files I created -->
<_CustomFiles Include="Includes\JavaScript\Bundled\*" />
<FilesForPackagingFromProject Include="%(_CustomFiles.Identity)">
<DestinationRelativePath>Includes\JavaScript\Bundled\*%(Filename)%(Extension) </DestinationRelativePath>
</FilesForPackagingFromProject>
</ItemGroup>
</Target>
<!-- Hook into the pipeline responsible for gathering files and tell it to add my files -->
<PropertyGroup>
<CopyAllFilesToSingleFolderForPackageDependsOn>
CustomCollectFiles;
$(CopyAllFilesToSingleFolderForPackageDependsOn);
</CopyAllFilesToSingleFolderForPackageDependsOn>
<CopyAllFilesToSingleFolderForMsdeployDependsOn>
CustomCollectFiles;
$(CopyAllFilesToSingleFolderForPackageDependsOn);
</CopyAllFilesToSingleFolderForMsdeployDependsOn>
</PropertyGroup>
I'm really stuck on this and wanted to ask for some help as to why the files might not be going. I suspect MSBuild doesn't use publish and that's why it works locally (because i'm selecting publish)?
Thanks so much for your help
UPDATE
Tried this as per comments below, but this time the files didn't even appear (so it seemed to not even run the tasks now). Any idea why? Did I type this right?
<Target Name="CustomCollectFiles">
<Exec Command="CreateMyFiles.bat" />
<!-- Generate Files -->
<ItemGroup>
<!-- Create an identity called _CustomFiles, and associate it to the files I created -->
<_CustomFiles Include="Includes\JavaScript\Bundled\*" />
<FilesForPackagingFromProject Include="%(_CustomFiles.Identity)">
<DestinationRelativePath>Includes\JavaScript\Bundled\*%(Filename)%(Extension) </DestinationRelativePath>
</FilesForPackagingFromProject>
</ItemGroup>
</Target>
<!-- Hook into the pipeline responsible for gathering files and tell it to add my files -->
<PropertyGroup>
<PipelineCollectFilesPhaseDependsOn>
CustomCollectFiles;
$(PipelineCollectFilesPhaseDependsOn);
</PipelineCollectFilesPhaseDependsOn>
</PropertyGroup>
UPDATE 2
When I take the above code, and place it into my pubxml file and then execute an actual publish, it works, but as far as I know our process is to just queue a build from TFS. Is it possible to hook into the above code block when simply queuing a build? Or do I need to publish?
to do a publish from TFS build you need to add the following arguments
/p:DeployOnBuild=true;PublishProfile=Release
obviously using your own PublishProfile name
In VS2012, the target was renamed from:
CopyAllFilesToSingleFolderForPackageDependsOn
to:
CopyAllFilesToSingleFolderForMsdeployDependsOn
Update: looks like the above Targets are not getting called from within VS2012 targets, can you replace it with a call to the Target "PipelineCollectFilesPhaseDependsOn"? That should fix it.
<PropertyGroup>
<PipelineCollectFilesPhaseDependsOn>
CustomCollectFiles;
$(PipelineCollectFilesPhaseDependsOn);
</PipelineCollectFilesPhaseDependsOn>
</PropertyGroup>
I'm using Visual Studio Team Build. My build compiles stuff and then runs some automated tests. If the tests fail, the build ends with status "Partially succeeded". When this happens, the only file in the drop directory is the build log. It seems that team build only copies the contents of the Binaries folder to the drop directory if the build ends with "Succeeded".
But, I really need to see the files from the Binaries directory to help me diagnose why the build only partially succeeded.
Is there a way to force team build to write to the drop directory when the build is only "Partially Succeeded"?
This is strange. The default behaviour is that the build output is copied to the drop location in case when the tests fail. Can you see in the build log why it partially succeeds?
I've forced it by adding the following to my TFSBuild.proj. It doesn't feel very neat though.
<PropertyGroup>
<CoreTestDependsOn>$(CoreTestDependsOn);SmokeTest</CoreTestDependsOn>
</PropertyGroup>
<Target Name="SmokeTest">
<!-- Exec stuff here to run some tests, output exit code to property SmokeTestExitCode. Use ContinueOnError="true" -->
<!-- Still create drop folder even if build ending with status "Partially Succeeded" -->
<CallTarget Condition="'$(IsDesktopBuild)'=='false' And '$(SmokeTestExitCode)'!='0'" Targets="DropBuild"/>
<!-- Now, after creating drop folder, raise error to cause "Partially Succeeded" instead of "Succeeded" -->
<Error Condition="'$(SmokeTestExitCode)'!='0'" Text="Smoke Test Failed with exit code=$(SmokeTestExitCode)"/>
</Target>
I'm in the process of developing several custom build scripts for TFS and I'd like to know if there are any best practices for developing, testing and deploying TFS build scripts.
Do you setup development and QC environments that are seperate from the production build server? Are there other ways to isolate the process of developing the scripts from the rest of the build process so that builds scripts under development don't interfere with "production" builds?
Team Build likes to create work items, update work items and add labels as part of the build process which I'd rather not have happen for a "test" build.
jMM
Check out my answer here: Modular TeamBuilds
You can keep core functionality factored out into a common MSBuild file that's included across all builds. Furthermore, all of these files are part of your broader branch structure, so they participate directly in your preexisting SDLC without any extra work. Thus:
If you're making risky changes to your build scripts, make them in a "dev" or "private" branch, just as you would with any other risky changes.
If you want a build definition that's just for quick validation, set properties like SkipLabel, SkipWorkItemCreation, etc to False in the *.targets file imported by that build definition.
To expand on #2 a bit, let's take your example of "production" vs "test" builds. You only want to turn on features like labeling in production builds. So you would remove the SkipLabel property from TFSBuild.proj (and also TFSBuild.Common.targets if it's defined there) and instead set it in TFSBuild.Production.targets and TFSBuild.Test.targets -- using two different values, of course.
As mentioned in the earlier question, TFSBuild.proj is the master msbuild file that controls how the rest of the build will operate. Here's what mine looks like:
<?xml version="1.0" encoding="utf-8"?>
<!-- DO NOT EDIT the project element - the ToolsVersion specified here does not prevent the solutions
and projects in the SolutionToBuild item group from targeting other versions of the .NET framework.
-->
<Project DefaultTargets="DesktopBuild" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="3.5">
<!-- Import configuration for all MyCompany team builds -->
<Import Project="MyCompany.TeamBuild.Common.targets"/>
<!-- Import build-specific configurations -->
<Import Condition="'$(BuildDefinition)'=='Dev - quick'" Project="MyCompany.TeamBuild.Quick.targets" />
<Import Condition="'$(BuildDefinition)'=='Main - full'" Project="MyCompany.TeamBuild.Full.targets" />
<Import Condition="'$(BuildDefinition)'=='Main - quick'" Project="MyCompany.TeamBuild.Quick.targets" />
<Import Condition="'$(BuildDefinition)'=='Release - full'" Project="MyCompany.TeamBuild.Full.targets" />
<!-- This would be much cleaner as we add more branches, but msbuild doesn't support it :(
Imports are evaluated declaratively at parse-time, before any tasks execute
<Target Name="BeforeEndToEndIteration">
<RegexReplace Input="$(BuildDefinition)" Expression=".*\s-\s" Replacement="">
<Output TaskParameter="Output" PropertyName="BuildType" />
</RegexReplace>
</Target>
<Import Condition="$(BuildType)==full" Project="MyCompany.TeamBuild.Full.targets" />
<Import Condition="$(BuildType)==quick" Project="MyCompany.TeamBuild.Quick.targets" />
-->
</Project>
By doing something similar, you can ensure that all builds from the Dev branch are "quick" builds (which for you means no labeling, etc), all builds from the Release branch are "full" builds, and builds from the Main branch can be either depending on which build definition the user launches from Visual Studio / TSWA. Myself, I have "quick" builds set up with Continuous Integration and "full" builds running nightly.