Mysteriously failing sandcastle build only when built by TeamCity - msbuild

I have a rather large solution, which contains two documentation projects based on Sandcastle + Sandcastle Help File Builder (SHFB). These projects both build correctly from the command line (msbuild project.shfb) and also using the beta version of SHFB Visual Studio 2010 integration.
When I run the build in TeamCity though, I get a mysterious build failure within the documentation build. The SHFB log says this:
[Sandcastle Help File Builder, version 1.9.3.0]
Cached Resolve Reference Links 2 Component. Copyright © 2006-2011, Eric Woodruff, All Rights Reserved
http://SHFB.CodePlex.com
Info: CachedResolveReferenceLinksComponent: Loaded 61 cached MSDN URL entries
Info: SaveComponent: Instantiating component.
Info: BuildAssembler: Building topic N:MyProject
Info: BuildAssembler: Building topic T:MyProject.ActionNotImplementedException
Info: BuildAssembler: Building topic AllMembers.T:MyProject.ActionNotImplementedException
Info: BuildAssembler: Building topic Methods.T:MyProject.ActionNotImplementedException
Info: BuildAssembler: Building topic Properties.T:MyProject.ActionNotImplementedException
Info: BuildAssembler: Building topic Overload:MyProject.ActionNotImplementedException.#ctor
Info: BuildAssembler: Building topic M:MyProject.ActionNotImplementedException.#ctor
Info: BuildAssembler: Building topic M:MyProject.ActionNotImplementedException.#ctor(System.String)
BUILDASSEMBLER : error : CachedCopyFromIndexComponent: An access error occured while attempting to load the file 'C:\Program Files (x86)\Sandcastle\Data\Reflection\mscorlib.xml'. The error message is: Could not find file 'C:\Program Files (x86)\Sandcastle\Data\Reflection\mscorlib.xml'. [C:\BuildAgent\work\37c2302839b8996f\Help\Output\Developer\Working\BuildReferenceTopics.proj]
Last step completed in 00:02:31.3827
</buildStep>
<buildStep step="Failed">
SHFB: Error BE0043: Unexpected error detected in last build step. See output above for details.
</buildStep>
</shfbBuild>
Sure enough, the file that Sandcastle is looking for (mscorlib.xml) is not there. But the build works outside of TeamCity, so I would conclude that Sandcastle is only looking for that file when TeamCity is onvolved. So, why does this only cause a failure in TeamCity and not from the command line within msbuild? I'd appreciate any troubleshooting hints because I'm out of inspiration.
Clarification (thanks #Sayed): The TeamCity build agent is the same computer where I can successfulyl run the command line build, so it's the same computer for everything mentioned above. The TeamCity Server is a different computer but that takes no part in the build.

I hit the same problem today, and I eventually managed to solve it: you just need to delete the cache files in the %USERPROFILE%\AppData\Local\EWSoftware\Sandcastle Help File Builder\Cache folder.
(note: since your problem is related to TeamCity, perhaps the files are in the TeamCity data folder instead)
In my case, I think it's because the cache files had been generated with an older version of SHFB, and were not compatible with the new version.

Related

Osquery MsBuild error msb1009

While building the Windows environment for OsQuery (on my Windows 10 VM) from their website(link: https://osquery.readthedocs.io/en/stable/development/windows-provisioning/), I am getting the msb1009 error during the phase where I have to run the tools\make-win64-binaries.bat command. I get the following result after running that command:
CMake Error at CMakeLists.txt:402 (project):
Failed to run MSBuild command:
C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/MSBuild/15.0/Bin/MSBuild.exe
to get the value of VCTargetsPath:
Microsoft (R) Build Engine version 15.7.179.6572 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.
MSBUILD : error MSB1009: Project file does not exist.
Switch: VCTargetsPath.vcxproj
Exit code: 1
-- Configuring incomplete, errors occurred!
See also "C:/Windows/System32/osquery/build/windows10/CMakeFiles/CMakeOutput.log".
Microsoft (R) Build Engine version 15.7.179.6572 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.
MSBUILD : error MSB1009: Project file does not exist.
Switch: osquery.sln
[-] osquery build failed.
I have been trying to make the osquery.sln file using that command and have looked online for solutions but without any success. Any help would be much appreciated!
Thanks in advance
Edit: Here is the output of running tools\make-win64-dev-env.bat and tools\make-win64-binaries.bat
tools\make-win64-dev-env.bat
tools\make-win64-dev-env.bat (contd..)
tools\make-win64-binaries.bat
Could you paste the full output of running the tools\make-win64-dev-env.bat and tools\make-win64-binaries.bat? Also have you tried closing out your shell and re-opening, or even worse -- reboot the system?
I ask because, as you note, it seems like the solution file never gets generated, which usually means there was either a missing dependency during provision, or some other issue when the script first ran. On first provision it's typically the case that a system reboot is needed, as Visual Studio community typically requires one. Further, we set a few shell environment variables that are leveraged during the build process, however those are supposed to be set at the end of the provisioning script.
Also feel free to hit us up in our Slack and check out the #windows channel :)
After a lot of code reading, researching online and trial and error, I found out that after a clean OS install, one would need to install git and then immediately clone the osquery repository on the user desktop rather than System32. This worked fine, at least for me. Just make sure to switch directories when opening command line with administrator mode.

SonarQube 5.6 - MSBuild Fakes Generation failing (SonarQube.Integration.targets)

I posted a similar question here.
Unfortunately, this issue is coming up again after having upgraded our build machines to run on Visual Studio Online 2015's Build and Release Manager.
This is the error that I get from a solution that generates Fakes assemblies used in unit testing:
D:\builds\TFS2015agent_2_work\1\.sonarqube\bin\targets\SonarQube.Integration.targets(240,5):
error MSB3491: Could not write lines to file "D:\builds\TFS2015agent_2_work\1\.sonarqube\out\\f_AnyCPU_Release_9840\FilesToAnalyze.txt".
The process cannot access the file 'D:\builds\TFS2015agent_2_work\1\.sonarqube\out\f_AnyCPU_Release_9840\FilesToAnalyze.txt' because it is being used by another process. [D:\builds\TFS2015agent_2_work\1\s\FakesFilePath\f.csproj] [D:\builds\TFS2015agent_2_work\1\s\FakesFileProj]
2016-09-13T20:01:37.6477261Z GENERATEFAKES : error : project compilation failed with exit code 1 [D:\builds\TFS2015agent_2_work\1\s\FakesFilePath\]
Does anyone have an idea of why this is happening? What process is causing the error? Could it possibly be related to the fakes compiling while SonarQube tries to access it?

where is the "TargetFrameworkSDKToolsDirectory" was defined

I was using msbuild build my sln and get error message "couldn't find 'AxImp.exe' which already exists under %Program files (x86)%\Microsoft sdks\windows\v8.1A. but seems it find sdk from v8.0A, output info point out the error was in Microsoft.Common.targets file(code see below). I didn't found where the "TargetFrameworkSDKToolsDirectory" was defined, anyone can help me?
environment: winblue(4.5.1 sdk v8.1A) without visual studio.
<ResolveComReference
TypeLibNames="#(COMReference)"
TypeLibFiles="#(COMFileReference)"
ResolvedAssemblyReferences="#(ReferencePath)"
WrapperOutputDirectory="$(InteropOutputPath)"
IncludeVersionInInteropName="$(IncludeVersionInInteropName)"
KeyContainer="$(KeyContainerName)"
KeyFile="$(KeyOriginatorFile)"
DelaySign="$(DelaySign)"
StateFile="#(_ResolveComReferenceCache)"
TargetFrameworkVersion="$(TargetFrameworkVersion)"
TargetProcessorArchitecture="$(ProcessorArchitecture)"
NoClassMembers="$(ComReferenceNoClassMembers)"
Silent="$(ResolveComReferenceSilent)"
EnvironmentVariables="$(ResolveComReferenceEnvironment)"
**SdkToolsPath="$(ResolveComReferenceToolPath)"**
ExecuteAsTool="$(ComReferenceExecuteAsTool)"
MSBuildArchitecture="$(ResolveComReferenceMSBuildArchitecture)"
ContinueOnError="$(ContinueOnError)">
<**ResolveComReferenceToolPath** Condition="'$(ResolveComReferenceToolPath)' == ''">$(**TargetFrameworkSDKToolsDirectory**)</ResolveComReferenceToolPath>
Depends on the version and platform you're targeting, but latest is at C:\Program Files (x86)\MSBuild\12.0\Bin\Microsoft.NetFramework.CurrentVersion.props, follow your imports, i.e. <Import Project=".targets" />. To get the values run MSBuild with /v:diag and all evaluated properties will be dumped and the start.
what ended up working for me was installing:
Windows Software Development kit (SDK) for windows 8
even though I'm on widows server 2016
https://developer.microsoft.com/en-us/windows/downloads/windows-8-sdk
I guess the clue was in my error:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(2428, 5): error MSB3086: Task could not find "LC.exe" using the SdkToolsPath "" or the registry key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v8.0A\WinSDK-NetFx40Tools-x86". Make sure the SdkToolsPath is set and the tool exists in the correct processor specific location under the SdkToolsPath and that the Microsoft Windows SDK is installed

The mystery of stuck inactive msbuild.exe processes, locked Stylecop.dll, Nuget AccessViolationException and CI builds clashing with each other

Observations:
On our Jenkins build server, we were seeing lots of msbuild.exe processes (~100) hanging around after job completion with around 20mb memory usage and 0% CPU activity.
Builds using different versions of stylecop were intermittently failing:
workspace\packages\StyleCop.MSBuild.4.7.41.0\tools\StyleCop.targets(109,7):
error MSB4131: The "ViolationCount" parameter is not supported by the "StyleCopTask" task.
Verify the parameter exists on the task, and it is a gettable public instance property.
Nuget.exe was intermittently exiting with the following access violation error (0x0000005):
.\workspace\.nuget\nuget install .\workspace\packages.config -o .\workspace\packages"
exited with code -1073741819.
MsBuild was launched in the following way via a Jenkins Matrix job, with 'BuildInParallel' enabled:
`msbuild /t:%Targets% /m
/p:Client=%Client%;LOCAL_BUILD=%LOCAL_BUILD%;BUILD_NUMBER=%BUILD_NUMBER%;
JOB_NAME=%JOB_NAME%;Env=%Env%;Configuration=%Configuration%;Platform=%Platform%;
Clean=%Clean%; %~dp0\_Jenkins\Build.proj`
After a lot of digging around and trying various things to no effect, I eventually ended up creating a new minimal solution which reproduced the issue with very little else going on. The issue turned out to be caused by msbuild's multi-core parallelisation - the 'm' parameter.
The 'm' parameter tells msbuild to spawn "nodes", these will remain alive after the build has ended, and are then re-used by new builds!
The StyleCop 'ViolationCount' error was caused by a given build re-using an old version of the stylecop.dll from another build's workspace, where ViolationCount was not supported. This was odd, because the CI workspace only contained the new version. It seems that once the StyleCop.dll was loaded into a given MsBuild node, it would remain loaded for the next build. I can only assume this is because StyleCop loads some sort of singleton into the nodes processs? This also explains the file-locking between builds.
The nuget access violation crash has now gone (with no other changes), so is evidently related to the above node re-use issue.
As the 'm' parameter defaults to the number of cores - we were seeing 24 msbuild instances created on our build server for a given job.
The following posts were helpful:
msbuild.exe staying open, locking files
http://www.hanselman.com/blog/FasterBuildsWithMSBuildUsingParallelBuildsAndMulticoreCPUs.aspx
http://stylecop.codeplex.com/discussions/394606
https://github.com/Glimpse/Glimpse/issues/115
http://msdn.microsoft.com/en-us/library/vstudio/ms164311.aspx
The fix:
Add the line set MSBUILDDISABLENODEREUSE=1 to the batch file which launches msbuild
Launch msbuild with /m:4 /nr:false
The 'nr' paremeter tells msbuild to not use "Node Reuse" - so msbuild instances are closed after the build is completed and no longer clash with each other - resulting in the above errors.
The 'm' parameter is set to 4 to stop too many nodes spawning per-job
I had the same issue. One old reference I found was in csproj files
<PropertyGroup>
<StyleCopMSBuildTargetsFile>..\packages\StyleCop.MSBuild.4.7.48.0\tools\StyleCop.targets</StyleCopMSBuildTargetsFile>
Also, I deleted the entire "Packages" folder that's located in the same folder as sln file after I closed the visual studio. It triggered VS to rebuild the folder and let go of the cache of the old version of stylecop
I've had the same issue for a while, builds were taking over 6 minutes to finish after some digging I found our it's node reuse fault so adding /m:4 /nr:false fixing my issue immediately

help building castle dynamic proxy

So I pulled the source from https://svn.castleproject.org/svn/castle/DynamicProxy/trunk/
Open it up in vs.net 2008
problems:
vs.net can't open the assembly.cs
assembly signing failed
What am I doing, rather NOT doing?
Update
So I downloaded nant, setup the .bat file in my PATH so it works in cmd prompt.
I ran:
nant default.build
Getting this error:
build failed, \buildscripts\common-project.xml (48,3)
invalid element . Unknown task or datatype.
How exactly do I build the dynamicProxy project now?
update
This is what I did, see screenshot:
oh and my nant is:
#echo off
"E:\dev\tools\nant-bin\nant-0.86-nightly-2009-05-05\bin\Nant.exe" %*
http://img697.imageshack.us/img697/5623/castlebuildscreenshot.png http://img697.imageshack.us/img697/5623/castlebuildscreenshot.png
You can read the FM (how to build.txt). :)
You need to run the build script first using NAnt (http://nant.sf.net). This will generate the assembly.cs file. Take a look at the .build files in the tree to see what they are doing.
As for the assembly signing failing, check the project settings to get rid of references to CastleKey.snk. It should sign it using DynProxy.snk (in theory).
UPDATE:
The issue with NUnit is now fixed. Do a clean check out. I really have no idea why you're getting that error. Which version of NAnt are you using? Make sure you have the latest (earlier do not have support for .NET 3.5)
You should be able to just pull the source from the trunk, and build with nant (I just did that and it worked). Ok, I lied, looks like the reference to NUnit is wrong, so the unit test project will not build correctly:
BUILD FAILED - 0 non-fatal error(s), 1 warning(s)
D:\OLD\DynamicProxy\buildscripts\common-project.xml(295,5):
'nunit-console.exe' failed to start.
The system cannot find the file specified
Total time: 1.2 seconds.
BUILD FAILED
Nested build failed. Refer to build
log for exact reason.
Total time: 3.4 seconds.
However the important stuff (assemblyinfo generation) will succeed and you should be able to just open Castle.DynamicProxy2-vs2008.sln, fix the reference to the NUnit assembly hit F5 and build the code with no issues.
I just did it on a clean check out, and it worked.
Generally if you're planning to do modifications in DP codebase, it is advised to go to the Castle user group first, and discuss it there.