I have this line in my build script
<Target Name="Deploy" DependsOnTargets="ServicesInstall;SitesTransfer" >
What I want to know is, in this example, what order will the targets get executed. Also, if ServiceInstall has dependencies do they get executed before or after SiteTransfer. In other words is the execution done in a depth first or breadth first manner?
Thanks,
Sachin
As an experiment I tried this:
<Target Name="Deploy" DependsOnTargets="ServicesInstall;SitesTransfer" />
<Target Name="ServicesInstall" DependsOnTargets="ServicesInstallDependency">
<Message Text="ServicesInstall" />
</Target>
<Target Name="ServicesInstallDependency">
<Message Text="ServicesInstallDependency" />
</Target>
<Target Name="SitesTransfer">
<Message Text="SitesTransfer" />
</Target>
and this was the output:
...
1>ServicesInstallDependency:
1> ServicesInstallDependency
1>ServicesInstall:
1> ServicesInstall
1>SitesTransfer:
1> SitesTransfer
...
However, I suspect the exact sequence is undefined. It is not documented on msdn.
In other words, msbuild will only guarantee that the constraints you specify are satisfied. If you need to guarantee SitesTransfer and its dependencies are executed before ServicesInstall, you should make ServicesInstall depend on SitesTransfer.
Related
I am creating a buildscript, where I'm outputting the TargetOutputs of an MSBuild, then wanting to call FXCop in a separate target, and using those outputs in the TargetAssemblies.
<Target Name="Build">
<MSBuild Projects="#(Projects)"
Properties="Platform=$(Platform);Configuration=$(Configuration);"
Targets="Build"
ContinueOnError="false">
<Output TaskParameter="TargetOutputs" ItemName="TargetDLLs"/>
</MSBuild>
<CallTarget Targets="FxCopReport" />
</Target>
<Target Name="FxCopyReport">
<Message Text="FXCop assemblies to test: #(TargetDLLs)" />
<FxCop
ToolPath="$(FXCopToolPath)"
RuleLibraries="#(FxCopRuleAssemblies)"
AnalysisReportFileName="FXCopReport.html"
TargetAssemblies="#(TargetDLLs)"
OutputXslFileName="$(FXCopToolPath)\Xml\FxCopReport.xsl"
ApplyOutXsl="True"
FailOnError="False" />
</Target>
When I run this, in the FxCopyReport target, the Message of TargetDLLs in empty, whereas if I put this in the Build target, it populates.
How can I pass/reference this value?
There is a blog post by Sayed Ibrahim Hashimi (co-author of Inside MSBuild book), describing the issue you ran into, dating back in 2005. Essentially CallTarget task is behaving weird. I'm not sure if it is a bug or designed behavior, but the behavior is still the same in MSBuild 4.0.
As a workaround, use normal MSBuild mechanism of setting order of execution of targets in MSBuild, using attributes DependsOnTargets, BeforeTargets or AfterTargets.
I was able to figure this one out.
Essentially, after the MSBuild step, I created an ItemGroup, which I then referenced in the calling Target.
<Target Name="Build">
<Message Text="Building Solution Projects: %(Projects.FullPath)" />
<MSBuild Projects="#(Projects)"
Properties="Platform=$(Platform);Configuration=$(Configuration);"
Targets="Build"
ContinueOnError="false">
<Output TaskParameter="TargetOutputs" ItemName="TargetDllOutputs"/>
</MSBuild>
<ItemGroup>
<TestAssemblies Include="#(TargetDllOutputs)" />
</ItemGroup>
</Target>
<Target Name="FXCopReport">
<Message Text="FXCop assemblies to test: #(TestAssemblies)" />
<FxCop
ToolPath="$(FXCopToolPath)"
RuleLibraries="#(FxCopRuleAssemblies)"
AnalysisReportFileName="$(BuildPath)\$(FxCopReportFile)"
TargetAssemblies="#(TestAssemblies)"
OutputXslFileName="$(FXCopToolPath)\Xml\FxCopReport.xsl"
Rules="$(FxCopExcludeRules)"
ApplyOutXsl="True"
FailOnError="True" />
<Message Text="##teamcity[importData id='FxCop' file='$(BuildPath)\$(FxCopReportFile)']" Condition="'$(TEAMCITY_BUILD_PROPERTIES_FILE)' != ''" />
</Target>
I may be asking the wrong question here, and I'm open to that, so I'll give a bit of background of what I'm trying to do. I invoke mstest via an msbuild project, after dynamically finding all test assemblies. I invoke mstest separately for every test assembly, so that the results can be imported into teamcity (my CI server) as soon as they're available, rather than waiting for all of them to be complete before showing any progress in TC.
The problem is that this runs a single test at a time, and combined with the slow overhead (even on an i7 quad, mstest takes 3-5 seconds overhead to open for each project) and many tests, the tests take a few minutes to run.
Using the msbuild task with BuildInParallel=true (and invoking with the /m parameter), it's possible to build several projects at once.
So what I'm trying to do is
get a list of all *.Tests.dll
Invoke the ExecMsTest target in the same project, in parallel, for each .dll
<PropertyGroup>
<MsTestExePath Condition="'$(MsTestExePath)'==''">C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\MSTest.exe</MsTestExePath>
<MsTestSettingsPath Condition="'$(MsTestSettingsPath)'==''">Project.testsettings</MsTestSettingsPath>
</PropertyGroup>
<ItemGroup>
<TestAssemblies Include="**\bin\**\*.Tests.dll" />
</ItemGroup>
<Target Name="RunTests">
<Message Text="Found test assemblies: #(TestAssemblies)" />
<MakeDir Directories="TestResults" />
<MsBuild Projects="#(ProjectsToBuild)" Targets="ExecMsTest" BuildInParallel="True" />
</Target>
<Target Name="ExecMsTest">
<Message Text="Running tests in $(TestAssembly)" />
<!-- show TC progress -->
<Message Text="##teamcity[progressMessage 'Running tests in $(TestAssembly).dll']" Importance="High" />
<PropertyGroup>
<MsTestCommand>"$(MsTestExePath)" /testcontainer:"$(TestAssembly)" /resultsfile:"TestResults\$(TestAssembly).trx" /testsettings:"$(MsTestSettingsPath)"</MsTestCommand>
</PropertyGroup>
<!-- Message Text="Exec: $(MsTestCommand)" / -->
<Exec Command="$(MsTestCommand)" ContinueOnError="true" />
<!-- import data to teamcity test results -->
<Message Text="##teamcity[importData type='mstest' path='TestResults\$(TestAssembly).trx']" />
<Message Text="Tests complete from $(TestAssembly)" />
However, this isn't quite right. You can see my itemgroup is called TestAssemblies, but I'm passing #(ProjectsToBuild) to mstest. This is because the msbuild task requires a differently-formatted item group, something like:
<ItemGroup>
<ProjectsToBuild Include="Project.mstest.proj">
<Properties>TestAssembly=Project.UI.Tests</Properties>
</ProjectsToBuild>
<ProjectsToBuild Include="Project.mstest.proj">
<Properties>TestAssembly=Project.Model.Tests</Properties>
</ProjectsToBuild>
</ItemGroup>
So this is the crux of my question, assuming I'm even asking the right thing: how do I transform the TestAssemblies itemgroup into something resembling the ProjectsToBuild itemgroup?
In case it's not obvious, the name of the items in TestAssemblies are the *.tests.Dll filenames, while I need that name to be a inside the item, and the name of the ProjectsToBuild item to all be the Project.mstest.proj file (since they're all invoking the same file).
Thanks to #Spider M9, this works:
<ItemGroup>
<TestAssemblies Include="**\bin\**\*.Tests.dll" />
</ItemGroup>
<Target Name="RunTests">
<Message Text="Found test assemblies: #(TestAssemblies)" />
<ItemGroup>
<TestAssembliesToBuild Include="Project.mstest.proj">
<Properties>TestAssembly=%(TestAssemblies.FileName);FullPath=%(TestAssemblies.FullPath)</Properties>
</TestAssembliesToBuild>
</ItemGroup>
<MakeDir Directories="TestResults" />
<MsBuild Projects="#(TestAssembliesToBuild)" Targets="ExecMsTest" BuildInParallel="True" />
</Target>
Running msbuild single-threaded, my entire build (which includes compiling, building application and database snapshots, deploying schema for a couple databases that get used in some of the unit tests, and then finally running mstest) took about 9m30s. After this change, it was taking ~7m.
However, prior to getting an answer to this question, I just tried running a single mstest instance, to see how much it would improve, and that takes about 4m50s (of which mstest takes slightly over 1 minute to run). The downside is I have to wait until all tests are complete before getting results, but considering the staggering improvement from 6m to 1m that's a perfectly acceptable trade-off.
To be clear, the only difference is that mstest is starting once, vs starting a dozen times, and presumably there is also some benefit from multitasking. I'm running this on a Core i7-860 (4 physical cores, 8 logical cores) and I suspect number of cores will highly influence the level of improvement this change makes.
Here is my new RunTests:
<Target Name="RunTests">
<Message Text="Found test assemblies: #(TestAssemblies)" />
<MakeDir Directories="TestResults" />
<!-- this executes mstest once, and runs all assemblies at the same time. Faster, but no output to TC until they're all completed -->
<PropertyGroup>
<MsTestCommand>"$(MsTestExePath)" #(TestAssemblies->'/testcontainer:"%(FullPath)"', ' ') /resultsfile:"TestResults\Results.trx" /testsettings:"$(MsTestSettingsPath)"</MsTestCommand>
</PropertyGroup>
<Message Text="##teamcity[progressMessage 'Running tests']" Importance="High" />
<Message Text="Exec: $(MsTestCommand)" />
<Exec Command="$(MsTestCommand)" ContinueOnError="true" />
<Message Text="##teamcity[importData type='mstest' path='TestResults\Results.trx']" />
</Target>
also, you need a testsettings file with: <Execution parallelTestCount="0"> (0 means autodetect, default is 1) and need to invoke msbuild using the /m parameter and/or <Msbuild BulidInParallel="true">
Try this:
<ItemGroup>
<TestAssemblies Include="**\bin\**\*.Tests.dll" />
<TestAssembliesToBuild Include="Project.mstest.proj">
<Properties>TestAssembly=%(TestAssemblies.FileName)</Properties>
</TestAssembliesToBuild>
</ItemGroup>
<Message Text="'%(TestAssembliesToBuild.Properties)'" />
Is there a way to check the existence of a target so that we can call it only when it exists?
You can make a Target depend on a other Target
...
<Target Name="Two" DependsOnTargets="One">
<Message Text="... comes Two." />
</Target>
<Target Name="One">
<Message Text="After One ..." />
</Target>
...
Your recent posts show that you try heavily to rely on calling Targets which is - as far as i understand it - against the philosophy of MSBuild.
Try rather to model dependencies between your Targets.
With MSBuild, as soon as an error occurs, the execution of the project is stopped unless ContinueOnError=true.
Is there a way to stop the execution of the project without raising an error?
I'd like to have this possibility because I have an existing set of msbuild project files and in some circumstances, I would need to stop processing the projects without raising an error because it is a normal exit point for the process and I don't want the person using the script to think something is wrong.
I know I could just set some property and put all remaining tasks conditional on this but I would like to avoid that.
As you explain it, you want to stop your build under special circumstance without raising an error because it is a normal exit point. Why not create a target doing nothing that will serve as your exit point. Under your special conditions you will call this target.
<target Name="BuildProcess">
<Message Text="Build starts"/>
...
<CallTarget Targets="Exit"
Condition="Special Condition"/>
<CallTarget Targets="Continue"
Condition="!(Special Condition)"/>
...
</target>
<target Name="Continue">
<Message Text="Build continue"/>
</target>
<target Name="Exit">
<!-- This target could be removed -->
<!-- Only used for logging here -->
<Message Text="Build ended because special condition occured"/>
</target>
The way to do this is the create another target to wrap the target you're interested in conditioning.
So if you have a scenario with a target like this:
<Target Name="MainTarget">
command - run under a certain condition
command - run under a certain condition
command - run under a certain condition
command - run under a certain condition
command - run under a certain condition
</Target>
The point is that you want to save having to use the condition statement a whole bunch of times, right?
To address this, you can do this:
<Target Name="MainWrapper" DependsOnTargets="EstablishCondition;MainTarget" />
<Target Name="EstablishCondition">
<SomeCustomTask Input="blah">
<Output PropertyName="TestProperty" TaskParameter="value" />
</SomeCustomTask>
</Target>
<Target Name="MainTarget" Condition="$(TestProperty)='true'">
command
command
command
command
command
</Target>
Eventually found an elegant solution for a similar issue. I just needed to rephrase my concern from "Break/interrupt MSBuild execution" to "Skip the next targets".
<PropertyGroup>
<LastInfoFileName>LastInfo.xml</LastInfoFileName>
<NewInfoFileName>NewInfo.xml</NewInfoFileName>
</PropertyGroup>
<Target Name="CheckSomethingFirst" BeforeTargets="DoSomething">
<Message Condition="ConditionForContinue"
Text="Let's carry on with next target" />
<WriteLinesToFile Condition="ConditionForContinue"
File="$(NewInfoFileName)"
Lines="#(SomeText)"
Overwrite="true" />
<Message Condition="!ConditionForContinue"
Text="Let's discard next target" />
<Copy Condition="!ConditionForContinue"
SourceFiles="$(LastInfoFileName)"
DestinationFiles="$(NewInfoFileName)" />
</Target>
<Target Name="DoSomething" Inputs="$(NewInfoFileName)"
Outputs="$(LastInfoFileName)">
<Message Text="DoSomethingMore" />
<Copy SourceFiles="$(NewInfoFileName)"
DestinationFiles="$(LastInfoFileName)" />
</Target>
This works ok with a command like:
msbuild.exe Do.targets /t:DoSomething
where target DoSomething Inputs/Outputs are correctly checked after the CheckSomethingFirst target was executed.
I have set up a build with Teamcity. See my build file below.
When the build is succesful and the tests pass, the build process just runs again and again indefinitely in a loop.
When the build fails, this does not happen.
I have tried to first set 60 second pause on buildtriggering, and finally disabled build triggering altogether. No difference.
What else could be the cause of this?
My MSBuild file looks like this:
<Project DefaultTargets="Build;Test" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="3.5">
<PropertyGroup>
<DeployDirectory>$(MSBuildProjectDirectory)\..\bin</DeployDirectory>
<DependencyDirectory>$(MSBuildProjectDirectory)\Dependencies</DependencyDirectory>
<LinqToSqlMapFolder>$(DeployDirectory)\LinqToSql</LinqToSqlMapFolder>
<NCoverVersionForMSI>$(BUILD_NUMBER)</NCoverVersionForMSI>
<NCoverVersionPeriod>$(BUILD_NUMBER)</NCoverVersionPeriod>
</PropertyGroup>
<ItemGroup>
<ProjectFiles Include="**\*.vbproj"/>
<ConfigFiles Include="**\*.config"/>
<MapFiles Include="**\*.linqtosql.config"/>
<TestAssemblies Include="$(DeployDirectory)\*.Test.dll"/>
<Dependencies Include="$(DependencyDirectory)\**\*" />
</ItemGroup>
<Target Name="Clean">
<MSBuild Projects="#(ProjectFiles)" Targets="Clean"/>
</Target>
<Target Name="Build">
<MSBuild Projects="#(ProjectFiles)" Targets="Rebuild">
<Output TaskParameter="TargetOutputs" ItemName="BuildOutput"/>
</MSBuild>
<Copy SourceFiles="#(BuildOutput)" DestinationFolder="$(DeployDirectory)" />
<Copy SourceFiles="#(Dependencies)" DestinationFolder="$(DeployDirectory)" SkipUnchangedFiles="true" />
<Copy SourceFiles="#(ConfigFiles)" DestinationFolder="$(DeployDirectory)" SkipUnchangedFiles="true" />
<Copy SourceFiles="#(MapFiles)" DestinationFolder="$(LinqToSqlMapFolder)" SkipUnchangedFiles="true" />
</Target>
<UsingTask AssemblyFile="$(DependencyDirectory)\Gallio\Gallio.MsBuildTasks.dll" TaskName="Gallio" />
<Target Name="Test">
<Gallio IgnoreFailures="true" Files="#(TestAssemblies)">
<Output TaskParameter="ExitCode" PropertyName="ExitCode"/>
</Gallio>
</Target>
</Project>
While it appears that this wasn't your issue, I ran into a similar looping problem of my own. I had enabled labeling in the project configuration. I was also using a check for modifications every 60 seconds rule to trigger the build. As a result, upon successful build, TeamCity would tag the build in the VCS and then 60 seconds later, it would see (it's own) modification and trigger another build.
To fix our problem, we just disabled labeling because we didn't want it anyways, but you can also configure a rule to ignore particular authors such that it won't trigger on modifications it made.
It appears there were some problems with the install of teamcity, and a backup of configuration following a reinstall solved the problem with exactly same configuration and buildscript.