I have a MSBuild script that I am executing through TeamCity.
One of the tasks that is runs is from Xheo DeploxLX CodeVeil which obfuscates some DLLs. The task I am using is called VeilProject. I have run the CodeVeil Project through the interface manually and it works correctly, so I think I can safely assume that the actual obfuscate process is ok.
This task used to take around 40 minutes and the rest of the MSBuild file executed perfectly and finished without errors.
For some reason this task is now taking 1hr 20 minutes or so to execute. Once the VeilProject task is finished the output from the task says it completely successfully, however the MSBuild script fails at this point. I have a task directly after the VeilProject task and it does not get outputted. Using diagnostic output from MSBUild I can see the following:
My questions are:
Would it be possible that the MSBuild
script has timed out? Once the task
has completed it is after a certain
timeout period so it just fails?
Why would the build fail with no
errors and no warnings?
[05:39:06]: [Target "Obfuscate"] Finished.
[05:39:06]: [Target "Obfuscate"] Saving exception map
[05:49:21]: [Target "Obfuscate"] Ended at 11/05/2010 05:49:21, ~1 hour, 48 minutes, 6 seconds
[05:49:22]: [Target "Obfuscate"] Done.
[05:49:51]: MSBuild output:
Ended at 11/05/2010 05:49:21, ~1 hour, 48 minutes, 6 seconds (TaskId:8)
Done. (TaskId:8)
Done executing task "VeilProject" -- FAILED. (TaskId:8)
Done building target "Obfuscate" in project "AMK_Release.proj.teamcity.patch.tcprojx" -- FAILED.: (TargetId:12)
Done Building Project "C:\Builds\Scripts\AMK_Release.proj.teamcity.patch.tcprojx" (All target(s)) -- FAILED.
Project Performance Summary:
6535484 ms C:\Builds\Scripts\AMK_Release.proj.teamcity.patch.tcprojx 1 calls
6535484 ms All 1 calls
Target Performance Summary:
156 ms PreClean 1 calls
266 ms SetBuildVersionNumber 1 calls
2406 ms CopyFiles 1 calls
6532391 ms Obfuscate 1 calls
Task Performance Summary:
16 ms MakeDir 2 calls
31 ms TeamCitySetBuildNumber 1 calls
31 ms Message 1 calls
62 ms RemoveDir 2 calls
234 ms GetAssemblyIdentity 1 calls
2406 ms Copy 1 calls
6528047 ms VeilProject 1 calls
Build FAILED.
0 Warning(s)
0 Error(s)
Time Elapsed 01:48:57.46
[05:49:52]: Process exit code: 1
[05:49:55]: Build finished
If the .exe is not returning standard exit codes then you may want to specify to ignore the exit code when using the Exec task with IgnoreExitCode="true". If that doesn't work then try the additional parameter IgnoreStandardErrorWarningFormat="true".
Related
I'm trying to speed up our unit tests. By setting xunit.parallelizeAssembly to true in in the app.config files I get multiple tests from different assemblies to run in parallel when run from Visual Studio. But when running on the build server it makes no difference in execution time and I can see than only one core is used.
In the paragraph on MSBuild Runner on this page it is suggested that the setting ParallelizeAssemblies would solve this problem. I'm currently running the tests with the "Visual Studio Test" build step (see image for configuration). Where do I put this setting?
I can't share all of the log but I believe the first and last part might contain good clues.
2017-04-20T16:51:10.5496891Z Executing the powershell script: C:\Tfs_Agent5\tasks\VSTest\1.0.32\VSTest.ps1
2017-04-20T16:51:12.9402898Z ##[debug]Calling Invoke-VSTest for all test assemblies
2017-04-20T16:51:12.9559206Z ##[warning]Install Visual Studio 2015 Update 1 or higher on your build agent machine to run the tests in parallel.
2017-04-20T16:51:13.0027923Z Working folder: C:\Tfs_Agent5\_work\1
2017-04-20T16:51:13.0027923Z Executing C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe "C:\Tfs_Agent5\_work\1\s\src\AwtSG.CompareToAros\bin\Release\AwtSG.Domain.MetOceanData.UnitTests.dll" "C:\Tfs_Agent5\_work\1\s\src\AwtSG.Domain.Dynamics.UnitTests\bin\Release\AwtSG.Domain.Dynamics.UnitTests.dll" "C:\Tfs_Agent5\_work\1\s\src\AwtSG.Domain.EcdisRouteFiles.UnitTests\bin\Release\AwtSG.Domain.EcdisRouteFiles.UnitTests.dll" "C:\Tfs_Agent5\_work\1\s\src\AwtSG.Domain.EcdisRouteFiles.UnitTests\bin\Release\AwtSG.Domain.NavigationUtilities.UnitTests.dll" "C:\Tfs_Agent5\_work\1\s\src\AwtSG.Domain.GeoSpatial.UnitTests\bin\Release\AwtSG.Domain.Geospatial.UnitTests.dll" "C:\Tfs_Agent5\_work\1\s\src\AwtSG.Domain.GeoSpatial.UnitTests\bin\Release\AwtSG.Domain.NavigationUtilities.UnitTests.dll" "C:\Tfs_Agent5\_work\1\s\src\AwtSG.Domain.MetOceanData.GribApi.UnitTests\bin\Release\AwtSG.Domain.MetOceanData.GribApi.UnitTests.dll" "C:\Tfs_Agent5\_work\1\s\src\AwtSG.Domain.MetOceanData.UnitTests\bin\Release\AwtSG.Domain.MetOceanData.UnitTests.dll" "C:\Tfs_Agent5\_work\1\s\src\AwtSG.Domain.NavigationUtilities.UnitTests\bin\Release\AwtSG.Domain.NavigationUtilities.UnitTests.dll" "C:\Tfs_Agent5\_work\1\s\src\AwtSG.Domain.Optimization.Evolutionary.IntegrationTests\bin\Release\AwtSG.Domain.MetOceanData.UnitTests.dll" "C:\Tfs_Agent5\_work\1\s\src\AwtSG.Domain.Optimization.Evolutionary.IntegrationTests\bin\Release\AwtSG.Domain.Optimization.Evolutionary.UnitTests.dll" "C:\Tfs_Agent5\_work\1\s\src\AwtSG.Domain.Optimization.Evolutionary.IntegrationTests\bin\Release\AwtSG.Domain.TechnicalPerformance.UnitTests.dll" "C:\Tfs_Agent5\_work\1\s\src\AwtSG.Domain.Optimization.Evolutionary.UnitTests\bin\Release\AwtSG.Domain.MetOceanData.UnitTests.dll" "C:\Tfs_Agent5\_work\1\s\src\AwtSG.Domain.Optimization.Evolutionary.UnitTests\bin\Release\AwtSG.Domain.Optimization.Evolutionary.UnitTests.dll" "C:\Tfs_Agent5\_work\1\s\src\AwtSG.Domain.Optimization.Evolutionary.UnitTests\bin\Release\AwtSG.Domain.TechnicalPerformance.UnitTests.dll" "C:\Tfs_Agent5\_work\1\s\src\AwtSG.Domain.Optimization.IntegrationTests\bin\Release\AwtSG.Domain.MetOceanData.UnitTests.dll" "C:\Tfs_Agent5\_work\1\s\src\AwtSG.Domain.Optimization.Mesh\bin\Release\AwtSG.Domain.NavigationUtilities.UnitTests.dll" "C:\Tfs_Agent5\_work\1\s\src\AwtSG.Domain.Simulation.IntegrationTests\bin\Release\AwtSG.Domain.MetOceanData.UnitTests.dll" "C:\Tfs_Agent5\_work\1\s\src\AwtSG.Domain.Simulation.UnitTests\bin\Release\AwtSG.Domain.NavigationUtilities.UnitTests.dll" "C:\Tfs_Agent5\_work\1\s\src\AwtSG.Domain.Simulation.UnitTests\bin\Release\AwtSG.Domain.Simulation.UnitTests.dll" "C:\Tfs_Agent5\_work\1\s\src\AwtSG.Domain.TechnicalPerformance.UnitTests\bin\Release\AwtSG.Domain.TechnicalPerformance.UnitTests.dll" "C:\Tfs_Agent5\_work\1\s\src\AwtSG.Domain.Units.UnitTests\bin\Release\AwtSG.Domain.Units.UnitTests.dll" "C:\Tfs_Agent5\_work\1\s\src\AwtSG.Dto.Mapping.UnitTests\bin\Release\AwtSG.Domain.NavigationUtilities.UnitTests.dll" "C:\Tfs_Agent5\_work\1\s\src\AwtSG.Dto.Mapping.UnitTests\bin\Release\AwtSG.Domain.Simulation.UnitTests.dll" "C:\Tfs_Agent5\_work\1\s\src\AwtSG.Dto.Mapping.UnitTests\bin\Release\AwtSG.Dto.Mapping.UnitTests.dll" "C:\Tfs_Agent5\_work\1\s\src\AwtSG.Dto.Simulation.Mapping.UnitTests\bin\Release\AwtSG.Domain.NavigationUtilities.UnitTests.dll" "C:\Tfs_Agent5\_work\1\s\src\AwtSG.Dto.Simulation.Mapping.UnitTests\bin\Release\AwtSG.Domain.Simulation.UnitTests.dll" "C:\Tfs_Agent5\_work\1\s\src\AwtSG.Dto.Simulation.Mapping.UnitTests\bin\Release\AwtSG.Dto.Simulation.Mapping.UnitTests.dll" "C:\Tfs_Agent5\_work\1\s\src\AwtSG.Dto.Simulation.UnitTests\bin\Release\AwtSG.Dto.Simulation.UnitTests.dll" "C:\Tfs_Agent5\_work\1\s\src\AwtSG.Dto.UnitTests\bin\Release\AwtSG.Dto.UnitTests.dll" "C:\Tfs_Agent5\_work\1\s\src\AwtSG.Infrastructure.UnitTests\bin\Release\AwtSG.Infrastructure.UnitTests.dll" "C:\Tfs_Agent5\_work\1\s\src\AwtSG.Numerics.UnitTests\bin\Release\AwtSG.Numerics.UnitTests.dll" "C:\Tfs_Agent5\_work\1\s\src\AwtSG.VoyageSimulationValidation\bin\Release\AwtSG.Numerics.UnitTests.dll" "C:\Tfs_Agent5\_work\1\s\src\AwtSG.WindowsService.VoyageSimulation.UnitTests\bin\Release\AwtSG.WindowsService.VoyageSimulation.UnitTests.dll" /Settings:"C:\Tfs_Agent5\_work\1\s\src\all.runsettings" /EnableCodeCoverage /InIsolation /logger:trx /TestAdapterPath:"C:\Tfs_Agent5\_work\1\s\src\packages"
2017-04-20T16:51:13.4090709Z Microsoft (R) Test Execution Command Line Tool Version 14.0.25420.1
2017-04-20T16:51:13.4090709Z Copyright (c) Microsoft Corporation. All rights reserved.
2017-04-20T16:51:15.7373080Z Starting test execution, please wait...
2017-04-20T16:51:19.4718867Z Warning: Diagnostic data adapter message: Could not find diagnostic data adapter 'Code Coverage'. Make sure diagnostic data adapter is installed and try again.
2017-04-20T16:51:33.2378718Z Information: [xUnit.net 00:00:01.2430136] Discovering:
2017-04-20T17:17:09.1501081Z Warning: System.AppDomainUnloadedException: Attempted to access an unloaded AppDomain. This can happen if the test(s) started a thread but did not stop it. Make sure that all the threads started by the test(s) are stopped before completion.
2017-04-20T17:17:10.3845539Z Total tests: 17704. Passed: 17679. Failed: 0. Skipped: 25.
2017-04-20T17:17:10.3845539Z Test Run Successful.
2017-04-20T17:17:10.3845539Z Test execution time: 25.8603 Minutes
2017-04-20T17:17:28.5726606Z Results File: C:\Tfs_Agent5\_work\1\TestResults\tfsservice_US-SUN-TFSBUILD 2017-04-20 09_57_25.trx
2017-04-20T17:17:29.3539333Z Publishing Test Results...
2017-04-20T17:17:44.9950924Z Test results remaining: 17704
2017-04-20T17:17:47.0264093Z Test results remaining: 16704
2017-04-20T17:17:49.0421061Z Test results remaining: 15704
2017-04-20T17:17:53.1985047Z Test results remaining: 14704
2017-04-20T17:17:54.9329389Z Test results remaining: 13704
2017-04-20T17:17:56.5579944Z Test results remaining: 12704
2017-04-20T17:17:58.2299179Z Test results remaining: 11704
2017-04-20T17:17:59.9331076Z Test results remaining: 10704
2017-04-20T17:18:01.5894343Z Test results remaining: 9704
2017-04-20T17:18:03.0113618Z Test results remaining: 8704
2017-04-20T17:18:04.3395079Z Test results remaining: 7704
2017-04-20T17:18:05.6052151Z Test results remaining: 6704
2017-04-20T17:18:06.8083476Z Test results remaining: 5704
2017-04-20T17:18:08.5896555Z Test results remaining: 4704
2017-04-20T17:18:09.9178475Z Test results remaining: 3704
2017-04-20T17:18:11.2304148Z Test results remaining: 2704
2017-04-20T17:18:12.5429604Z Test results remaining: 1704
2017-04-20T17:18:13.8867197Z Test results remaining: 704
2017-04-20T17:18:25.5277535Z Published Test Run :
Note the warning that VS2015 Update 1 must be installed. This is what the About dialog looks like on the build agent (Update 3 is installed):
Parallel run is available in VS2015 Update 1 and later, make sure that you are using the right VS version to run the test in parallel.
I have a solution with 109 projects. A mix of all - .NET, Silverlight, MVC, Web Applications, Console applications.
Now I build it on the console using msbuild. It takes some time. Understandable - lots of projects, lots of files.
But when I build it the second time right after the first - it still takes lots of time, even if nothing is actually built - the diag msbuild log confirms it.
For example, here is the Task performance summary for the first full build:
Task Performance Summary:
4 ms GetSilverlightItemsFromProperty 1 calls
13 ms Move 1 calls
20 ms GetReferenceAssemblyPaths 27 calls
28 ms GetFrameworkPath 190 calls
29 ms ValidateSilverlightFrameworkPaths 163 calls
72 ms AssignCulture 192 calls
75 ms ResolveKeySource 179 calls
79 ms MakeDir 200 calls
95 ms CreateProperty 260 calls
100 ms CreateCSharpManifestResourceName 122 calls
102 ms Delete 442 calls
112 ms GenerateResource 3 calls
123 ms CopyFilesToFolders 1 calls
177 ms ReadLinesFromFile 190 calls
179 ms CreateHtmlTestPage 31 calls
181 ms CallTarget 190 calls
184 ms GetSilverlightFrameworkPath 163 calls
211 ms Message 573 calls
319 ms CreateSilverlightAppManifest 97 calls
354 ms FileClassifier 119 calls
745 ms ConvertToAbsolutePath 190 calls
868 ms PackagePlatformExtensions 94 calls
932 ms AssignProjectConfiguration 190 calls
1625 ms CategorizeSilverlightReferences 163 calls
1722 ms ResourcesGenerator 60 calls
2467 ms WriteLinesToFile 118 calls
5589 ms RemoveDuplicates 380 calls
8207 ms FindUnderPath 950 calls
17720 ms XapPackager 97 calls
38162 ms Copy 857 calls
38934 ms CompileXaml 119 calls
40567 ms Exec 14 calls
55275 ms ValidateXaml 119 calls
65845 ms AssignTargetPath 1140 calls
83792 ms Csc 108 calls
105906 ms ResolveAssemblyReference 190 calls
1163988 ms MSBuild 471 calls
msbuild claims Time Elapsed 00:08:39.44
Fine. Now I run the same command line again and get the following:
Task Performance Summary:
1 ms GetSilverlightItemsFromProperty 1 calls
11 ms WriteLinesToFile 1 calls
17 ms GetReferenceAssemblyPaths 27 calls
24 ms GetFrameworkPath 190 calls
32 ms ValidateSilverlightFrameworkPaths 163 calls
43 ms CopyFilesToFolders 1 calls
47 ms GenerateResource 3 calls
60 ms ResolveKeySource 179 calls
66 ms MakeDir 200 calls
69 ms AssignCulture 192 calls
70 ms PackagePlatformExtensions 94 calls
76 ms Delete 432 calls
89 ms CreateProperty 260 calls
98 ms CreateCSharpManifestResourceName 122 calls
136 ms GetSilverlightFrameworkPath 163 calls
156 ms CallTarget 190 calls
182 ms CreateHtmlTestPage 31 calls
207 ms XapPackager 97 calls
215 ms ReadLinesFromFile 190 calls
217 ms Message 573 calls
271 ms CreateSilverlightAppManifest 97 calls
350 ms FileClassifier 119 calls
526 ms ConvertToAbsolutePath 190 calls
795 ms AssignProjectConfiguration 190 calls
1658 ms CategorizeSilverlightReferences 163 calls
2237 ms Exec 2 calls
5703 ms RemoveDuplicates 380 calls
6948 ms Copy 426 calls
7550 ms FindUnderPath 950 calls
17126 ms CompileXaml 119 calls
54495 ms ValidateXaml 119 calls
78953 ms AssignTargetPath 1140 calls
97374 ms ResolveAssemblyReference 190 calls
603295 ms MSBuild 471 calls
msbuild claims Time Elapsed 00:05:25.70.
This poses the following questions:
Why ResolveAssemblyReference takes so much time in the second build? All the cache files created in the first build are still there. Nothing has changed. So how come it is taking almost the same as before - 97 seconds vs 106 seconds?
Why ValidateXaml and CompileXaml are running at all? I mean nothing has changed at all since the full build!
Now I repeat the same experiment, but this time I build with devenv on the command line instead of msbuild. As with msbuild no parallel builds are used and the log level is on diag.
devenv does not present such a nice summary at the end, it has to be aggregated manually from the per project summaries.
The results amazed me. I used the following powershell script to aggregate the elapsed time:
Param(
[Parameter(Mandatory=$True,Position=1)][string]$log
)
[timespan]::FromMilliseconds((sls -SimpleMatch "Time Elapsed" $log |% {[timespan]::Parse(($_ -split ' ')[2]) } | measure -Sum TotalMilliseconds).Sum).ToString()
Building exactly the same solution from exactly the same standing point with devenv on the command line took 00:06:10.9000000 the first build and 00:00:03.1000000 the second. It is just 3 seconds !!!.
I have also written a powershell script to aggregate the statistics:
Param(
[Parameter(Mandatory=$True,Position=1)][string]$log
)
$summary=#{}
cat $log |% {
if ($collect) {
if ($_ -eq "") {
$collect = $false;
} else {
$tmp = ($_ -replace '\s+', ' ') -split ' ';
$cur = $summary[$tmp[3]];
if (!$cur) {
$cur = #(0, 0);
$summary[$tmp[3]] = $cur;
}
$cur[0] += $tmp[1];
$cur[1] += $tmp[4];
}
} else {
$collect = $_ -eq "Task Performance Summary:"
}
}
$summary.Keys |% {
$stats = $summary[$_];
$ms = $stats[0];
$calls = $stats[1];
[string]::Format("{0,10} ms {1,-40} {2} calls", $ms,$_,$calls);
} | sort
Running it on the log of the first (full) build produces the following output:
5 ms ValidateSilverlightFrameworkPaths 82 calls
7 ms Move 1 calls
9 ms GetFrameworkPath 108 calls
11 ms GetReferenceAssemblyPaths 26 calls
14 ms AssignCulture 109 calls
16 ms ReadLinesFromFile 108 calls
18 ms CreateCSharpManifestResourceName 61 calls
18 ms ResolveKeySource 97 calls
23 ms Delete 268 calls
26 ms CreateProperty 131 calls
41 ms MakeDir 118 calls
66 ms CallTarget 108 calls
70 ms Message 326 calls
75 ms ResolveNonMSBuildProjectOutput 104 calls
101 ms GenerateResource 1 calls
107 ms GetSilverlightFrameworkPath 82 calls
118 ms CreateHtmlTestPage 16 calls
153 ms FileClassifier 60 calls
170 ms CreateSilverlightAppManifest 49 calls
175 ms AssignProjectConfiguration 108 calls
279 ms ConvertToAbsolutePath 108 calls
891 ms CategorizeSilverlightReferences 82 calls
926 ms PackagePlatformExtensions 47 calls
1291 ms ResourcesGenerator 60 calls
2193 ms WriteLinesToFile 108 calls
3687 ms RemoveDuplicates 216 calls
5538 ms FindUnderPath 540 calls
6157 ms MSBuild 294 calls
16496 ms Exec 4 calls
19699 ms XapPackager 49 calls
21281 ms Copy 378 calls
28362 ms ValidateXaml 60 calls
29526 ms CompileXaml 60 calls
66846 ms AssignTargetPath 654 calls
81650 ms Csc 108 calls
82759 ms ResolveAssemblyReference 108 calls
Now, for the second build the results are:
1 ms AssignCulture 1 calls
1 ms CreateProperty 1 calls
1 ms Delete 2 calls
1 ms ValidateSilverlightFrameworkPaths 1 calls
3 ms AssignTargetPath 6 calls
3 ms ConvertToAbsolutePath 1 calls
3 ms PackagePlatformExtensions 1 calls
3 ms ReadLinesFromFile 1 calls
3 ms ResolveKeySource 1 calls
4 ms ResolveNonMSBuildProjectOutput 1 calls
5 ms CreateCSharpManifestResourceName 1 calls
5 ms GetFrameworkPath 1 calls
10 ms CategorizeSilverlightReferences 1 calls
11 ms CallTarget 1 calls
11 ms FileClassifier 1 calls
11 ms FindUnderPath 5 calls
11 ms MakeDir 1 calls
13 ms Copy 2 calls
17 ms GetSilverlightFrameworkPath 1 calls
17 ms RemoveDuplicates 2 calls
30 ms AssignProjectConfiguration 1 calls
32 ms Message 25 calls
239 ms ResolveAssemblyReference 1 calls
351 ms MSBuild 2 calls
687 ms CompileXaml 1 calls
1413 ms ValidateXaml 1 calls
We are talking about exactly the same solution here !
Finally, here are the scripts I used to build with the solution:
msbuild:
#setlocal
set SHELFSET=msbuild
set MSBUILDLOGVERBOSERARSEARCHRESULTS=true
set AppConfig=app.config
set Disable_CopyWebApplication=true
set MvcBuildViews=false
call \tmp\undo.cmd
del /a:-R /s/q *.*
tf unshelve %SHELFSET% /recursive /noprompt
msbuild DataSvc.sln
msbuild Main.sln /v:diag > \tmp\00.Main.msbuild.full.log
msbuild Main.sln /v:diag > \tmp\01.Main.msbuild.incr.log
msbuild Main.sln /v:diag > \tmp\02.Main.msbuild.incr.log
#endlocal
devenv:
#setlocal
set SHELFSET=msbuild
set MSBUILDLOGVERBOSERARSEARCHRESULTS=true
set AppConfig=app.config
set Disable_CopyWebApplication=true
set MvcBuildViews=false
call \tmp\undo.cmd
del /a:-R /s/q *.*
tf unshelve %SHELFSET% /recursive /noprompt
msbuild DataSvc.sln
devenv Main.sln /build > \tmp\00.Main.devenv.full.log
devenv Main.sln /build > \tmp\01.Main.devenv.incr.log
devenv Main.sln /build > \tmp\02.Main.devenv.incr.log
#endlocal
My tests tell me that msbuild is a piece of junk and I should never use it on the command line to build my C# solutions. https://connect.microsoft.com/VisualStudio/feedback/details/586358/msbuild-ignores-projectsection-projectdependencies-in-sln-file-and-attempts-to-build-projects-in-wrong-order adds to this feeling.
But maybe I am wrong after all and a simple tweak would make msbuild as efficient on the second build as devenv is.
Any ideas how to make msbuild behave sanely on the second build?
EDIT 1
The CompileXaml task is part of the MarkupCompilePass1 target found in C:\Program Files (x86)\MSBuild\Microsoft\Silverlight\v5.0\Microsoft.Silverlight.Common.targets:
<Target Name="MarkupCompilePass1"
DependsOnTargets="$(CompileXamlDependsOn)"
Condition="'#(Page)#(ApplicationDefinition)' != '' " >
<CompileXaml
LanguageSourceExtension="$(DefaultLanguageSourceExtension)"
Language="$(Language)"
SilverlightPages="#(Page)"
SilverlightApplications="#(ApplicationDefinition)"
ProjectPath="$(MSBuildProjectFullPath)"
RootNamespace="$(RootNamespace)"
AssemblyName="$(AssemblyName)"
OutputPath="$(IntermediateOutputPath)"
SkipLoadingAssembliesInXamlCompiler="$(SkipLoadingAssembliesInXamlCompiler)"
TargetFrameworkDirectory="$(TargetFrameworkDirectory)"
TargetFrameworkSDKDirectory="$(TargetFrameworkSDKDirectory)"
ReferenceAssemblies ="#(ReferencePath);#(InferredReference->'$(TargetFrameworkDirectory)\%(Identity)')"
>
<Output ItemName="Compile" TaskParameter="GeneratedCodeFiles" />
<!-- Add to the list list of files written. It is used in Microsoft.Common.Targets to clean up
for a next clean build
-->
<Output ItemName="FileWrites" TaskParameter="GeneratedCodeFiles" />
<Output ItemName="_GeneratedCodeFiles" TaskParameter="GeneratedCodeFiles" />
</CompileXaml>
<Message Text="(Out) GeneratedCodeFiles: '#(_GeneratedCodeFiles)'" Condition="'$(MSBuildTargetsVerbose)'=='true'"/>
</Target>
As we can see - no Inputs and no Outputs.
Next, the diag msbuild log for the second build does not contain any suspicious words like "rebuilding".
Finally, I would like to notice that both msbuild and devenv were exercised under exactly the same circumstances and none employed the multi threaded build. Yet the difference is abysmal - more than 5 minutes (msbuild) vs 3 seconds (devenv, command line).
Still a complete mystery to me.
EDIT 2
I know now more about how devenv build works. It uses a heuristic to determine whether the current project has to be handed over to msbuild in the first place. This heuristic is enabled by default, but can be disabled by setting the DisableFastUpToDateCheck msbuild property to true.
Now, it actually takes more than 3 seconds for a command line devenv build to figure out whether there is need to run msbuild or not. All in all for the solution like mine it could take 20 seconds or even 30 seconds to decide that nothing needs to be passed to msbuild.
This heuristic is the sole reason for this huge different in time. I guess the Visual Studio team recognised the poor quality of the standard build scripts (where the tasks like MarkupCompilePass1 are not driven by inputs and outputs) and decided to come up with a way to skip msbuild in the first place.
But there is a catch - the heuristic only inspects the csproj file, none of the imported targets files are examined. In addition, it knows nothing about implicit dependencies - like TypeScript files referenced from other TypeScript files. So, if your TypeScript files reference other TypeScript files that belong to a different project and are not linked to explicitly from the project file - the heuristic does not know about them and you had better have DisableFastUpToDateCheck = true. The build will be slower, but at least it will be correct.
Bottom line - I do not know how to fix msbuild and apparently the devenv guys neither. That seems to be the reason for them inventing the heuristic.
First, take a look at that diagnostic log you're generating. Actually, first use a file logger rather than console operators to pipe console output to the log, then take a look at them logs!
Actually, instead of /v:diag >msbuild.log, use this:
/v:min /fl3 /flp3:warningsonly;logfile=msbuild.wrn /fl4 /flp4:errorsOnly;logfile=msbuild.err /fl5 /flp5:Verbosity=diag;logfile=msbuild.log
Now your console buffer thanks you, and so do your developers for including the foresight to keep separate error-only and warning-only logs for debugging.
Now examine that diagnostic MsBuild log, and CTRL+F for the targets that are taking a long time to run. Do you see any verbiage that denotes the target is running again even though nothing has changed? To skip a build, a target will need to have defined inputs and outputs. If the inputs (.cs) are newer than the outputs (.dll, .pdb), then it knows something must have changed and trigger a new build
Those CompileXaml targets I believe are in the WinFx targets and do have defined inputs and outputs, can you locate the output text for one of those long-running cases and determine if an error caused it to rebuild? Does it say "Rebuilding X completely because Y could not be found"?
Lastly, here's a fun trick to speed up your build from the command line!
msbuild.exe /m
This will build projects separately across multiple threads.
When I create a plan in Bamboo and add a task for running CxxTest test code(running function TS_ASSERT(1==1) or st). When I try to run for checking failure (TS_ASSERT(1==2)), this test case is fail and Bamboo output a log as:
12-Mar-2014 15:12:07 Failed 1 and Skipped 0 of 2 tests
12-Mar-2014 15:12:07 Success rate: 50%
12-Mar-2014 15:12:07 Failing task since return code was 1 while expected 0
So, does anyone here know why bamboo can understand the test result, and what is the return code here(return code was 1 while expected 0)?
From my observation, one windows, Bamboo consider value of the %ERRORLEVEL% as the result of the task. so return code was 1 while expected 0 means your task is returning 1 and Bamboo is expecting 0. Yes, it's expecting 0 since it considers any value other than 0 as failure.
I have a console application that takes input command line arguments. I have to schedule this task on Windows 8 using Win32.TaskScheduler. The problem is whenever my command line arguments length exceeds 450 characters, i get a warning like this :
Task registered task "TaskName" , but not all specified triggers will start the task. User Action: Ensure all the task triggers are valid as configured. Additional Data: Error Value: 2147944183.
And the task does not run eventually at the run time.
Is there any limit on command line arguments' length?
I encountered a similar issue with scheduled tasks and command line arguments that exceeded 260 characters. We got the same useless error that you did.
Eventually we had to change the command line arguments so they were smaller (length of file paths in argument list)
We had this issue on Windows Server 2012 R2 64 bit, I'm not sure if the bitness has anything to do with it...
On Teamcity, my project's build log looks like this:
[Build] MSBuild (28s)
[CoreCompile] Csc (6s)
[RunCodeAnalysis] CodeAnalysis (11s)
[StyleCop] StyleCopTask (9s)
[Build] MSBuild (9s)
[CoreCompile] Csc
[RunCodeAnalysis] CodeAnalysis (8s)
[StyleCop] StyleCopTask
That's a simplified extract, the full log is thousands of lines long. Anyway, those lines show how long was spent in each msbuild task (if the time in brackets is omitted, I understand that means it took less than one second).
Is it possible for Teamcity to plot this information in a graph, accumulating similar tasks? So for the example above, the graph would show 6 seconds for C# compiler, 19 seconds for CodeAnalysis, and 9 seconds for StyleCop.
For projects with multiple 'build steps', Teamcity shows the time spent in each step in a table under the 'PerfMon' tab. I like that. But my project is one long 'build step' (msbuild). I want to know how time is spent within it.
Motivation: our build is very slow. I'm curious how long is being spent in Style Cop and Code Analysis, compared to actually compiling code (Csc is the C# compiler).
If you are ok with a simple console output, try to call MsBuild with the PerformanceSummary switch (/clp:PerformanceSummary).
At the end of the build, it outputs a detailed summary like the following.
...
14 ms SplitResourcesByCulture 3 calls
18 ms ResolveProjectReferences 3 calls
22 ms PostBuildEvent 1 calls
28 ms CleanReferencedProjects 3 calls
48 ms UpdateAssemblyInfo 1 calls
51 ms CoreResGen 3 calls
74 ms CoreClean 3 calls
103 ms _CopyOutOfDateSourceItemsToOutputDirectory 2 calls
177 ms _CopyFilesMarkedCopyLocal 3 calls
293 ms CheckPrerequisites 3 calls
327 ms GenerateTemporaryTargetAssembly 1 calls
329 ms Clean 5 calls
460 ms MarkupCompilePass2 1 calls
627 ms ResolveAssemblyReferences 3 calls
890 ms RestorePackages 3 calls
891 ms MarkupCompilePass1 1 calls
936 ms CoreCompile 4 calls
4583 ms Rebuild 4 calls
12133 ms Setupkit 1 calls
24258 ms CompileAndTest 1 calls