We have a problem with the TFS build agent intermittently hanging while building our solution. We have some custom build actions, we're using eazfuscator, and we have some post build actions as well.
So it's quite possible we are causing the problem. We've identified that the solution (filled with C# projects) starts compiling but does not finish. What we need is the log file from MSBuild/csc, but because the solution never finishes, those logs never go to the build drop.
I need help finding the log file on the build agent. Any ideas?
Thanks!!
I suggest you to copy the MSBuild command which is generated in TFS build for code compilation, run the same command on build agent server manually from command prompt. Here, you will get more details to figure out the cause build for hanging issue.
Related
Our projects all use CMake, and Fabric seems to require a script run in XCode's build environment to extract information. CMake doesn't seem to have a way to add a run script build phase.
So, I tried running the script manually after setting the following manually from known values in CMake:
INFOPLIST_PATH
BUILT_PRODUCTS_DIR
DWARF_DSYM_FILE_NAME
DWARF_DSYM_FOLDER_PATH
PROJECT_DIR
As a result, there were no errors when running the script but ..also nothing happened. I just got a "Launching uploader in validation mode" and then the process exited.
Is it possible I could get a full run-down of what the program needs in order to run? Our projects are built on a build server so having to VNC in and launch xcode to build is not really an option.
Thanks in advance.
Since you're using CMake, instead of using the run script build phase, I'd use the upload-symbols script as that will be a more reliable way to upload the dSYMs to Crashlytics.
We have CI set up on a solution within the company.
The build was taking roughly 13 minutes in total, which seemed a bit a too long. After some digging around, I found out that the we were not passing the /maxcpucount switch to the msbuild command, and so each project was being built in sequence as opposed to parallel. Adding this switch dropped our build time down to 3 minutes.
However, we started seeing builds intermittently failing with the message that a cached nuget package was already being used by another process. The project that would fail to build, and the locked nuget package would change every time.
This turned out to be because we were building multiple projects within the same solution at the same time, and we could get the circumstance whereby two projects building in parallel tried to access the same locally cached nuget package at the same time.
We surely can't be the only people with this problem, as it seems like it would be quite common. Does anyone have experience with this problem? Are we doing something wrong? How can we prevent these builds from failing?
So I finally figured what was causing this, although I can't figure out why.
In our Teamcity MSBuild step, we had our Working Directory set to %build.root%. Removing this value, so that the default of the checking directory was used, appears to have stopped that error from occurring.
We build our solution using msbuild 4.0 from TeamCity. Our continuous build uses up quite a lot of resources, both on the build machine, and on our central signing and obfuscation servers. One thing I've noticed is that even when a project fails to compile, the build continues, and other projects that do compile get signed and obfuscated.
Is there some way to make the build halt as soon as something fails?
The MsBuild task actually supports a parameter StopOnFirstFailure. However, I can't seem to get it to have any effect.
Can I use this feature to do what I need? I'm prepared to edit e.g. the Microsoft.Common.Targets file on the build servers.
I found this answer on StackOverflow that involves emitting a proj file from the solution and then editing it. I guess I could automate that process on our build servers, but it seems a lot of work to achieve a fairly basic requirement.
I have a situation where I for debugging purposes would like to "build like my build agent, but locally on my developer machine" - and for this to work I need to know the exact msbuild command that is executed on my build agent.
Unfortunately I cannot seem to find this from either of the logs available from the build view.
Anyone can help?
Changed diagnostics to "Normal" and there it was.
I've a solution with 15 projects (14 class libraries and one web application). Each class library has corresponding test project (i.e. if I have MyApp.Services project there exists MyApp.Services.Tests -- using NUnit). Everything is written in VB.NET. The problem is that when VS tries to compile any of *.Tests project it stops responding (the bigger the project the longer the period without reposnse). I don't know where to start looking for an issue. I'll add that I've R# 4.5 installed.
UPDATE 1:
Is there any way to benchmark a build in visual studio? To get build times for every project?
UPDATE 2:
It seems that there is no difference after disabling R#.
Try turning on verbose logging for the build
Tools...Options...Projects and Solutions...Build and Run..."MSBuild project build output verbosity"
This should help you get a better picture of what is going on.
Disabling Resharper will probably help.
As for the benchmark, try building with msbuild with the following options, it will print statistics on build process at the end.
msbuild yoursolution.sln /verbosity:diagnostic
Try closing the tool panes associated with unit testing.
Have you tried disabling Resharper 4.5, using the Tools->Addins menu, and tried building again?
Also, is there a difference in time if you shutdown VS, restart it and load your solution and try building again before you do anything else. It might be that the build times get slower over time?