If I Build my solution from VS, it takes less than a minute to do all the checks to tell me all the projects have been built. If I do the same in team foundation build, it takes closer to 20 minutes.
i define as "items to build" only the solution (.sln file) and solution has 32 "projects".
Check the build definition workspace, make sure you are only pulling doen the code you need for the build.
Also TFS does a clean compile, I.e. it pulls down all of the code then rebuilds everything from scratch. How long does a clean build take locally? Less than a minute to build 32 projects seems quick so I suspect that your local build is incremental rather than full.
Run a build with diangnostic loging, this should give you a clue to the parts that are taking the time.
Related
I'm working on a c++ project built with cmake+ninja with approx 1200 build targets on a 64 thread computer.
There's one translation unit that takes 10min to compile, most others are comparably fast such that a build of all other targets together takes (building on all threads) only about 9 minutes. The slow translation unit is rather independent of the rest, so it doesn't have to be scheduled late, but as it turns out is is scheduled late by default, such that a complete build takes me between 15 and 20 minutes, and at the end there is only one thread working with almost all other targets done. The build would be faster for me, if the slow translation unit would be scheduled first, blocking one thread for about 10 minutes, while all other threads work on the rest of the project and the entire project is built within 10min.
Is there a way in cmake or ninja to shift the priorities for scheduling to point out slow or "please early" targets without messing up dependencies?
As of February 27, 2021, the answer is no. There are some open issues (#232, #376) and an abandoned PR (#1333) on GitHub requesting this feature in base Ninja. CMake does not provide any way to prioritize a target (at least through 3.20) either.
Messing with dependencies (even order-only) doesn't help here (as you likely know) because that would just force smaller targets to start either completely before or completely after the long target. A priority hint is what's truly needed here.
The only workaround I can think of (and it's not a great one), is to split your long target out into a separate ExternalProject and create a superbuild that builds the large target and the independent portion at the same time. This would require significant restructuring and would be a non-starter for a lot of projects. It might be worth the pain if you're losing a lot of development time to this issue, though.
In XAML build system in VS2012, there is an check box option "Build even if nothing has changed since the previous build", when Schedule option is selected.
This is missing in VNext build and the problem is that nightly build is fired even if no code was committed during the day. In my case it takes two hours to build with complete test suite.
Is there an easy workaround or plug in to achieve this?
Thanks
In TFS VNext build system Microsoft removed this option.
I would use an alternative instance of a workaround, you can create a build definition with a CI-trigger.
Another benefits of this practice is you get fast feedback if a change can not be integrated in the code base.
In this case you maybe need more than one build agent to run parallel builds in the case of parallel check-ins.
There is a feature request for it. But I think MS will not realize this request
https://visualstudio.uservoice.com/forums/121579-visual-studio-2015/suggestions/16300498-add-build-event-if-nothing-has-changed-since-prev
My BizTalk Project Rebuild takes very very long time especially for MAP Projects, this is relatively very small schema and before it was taking very less time but suddenly the REBUILD time is up to 30-40 mins.
Please provide your expect comment on and if you known any cause for this.
Regards
I have noticed that with BTS 2016 / VS2015 the maps build very slowly. I can't explain why but running the build from a visual studio command prompt results in much faster builds. It's a bit of a pain because need to remember to close VS first.
Navigate to the solution folder and run "msbuild .sln"
Used Rob Bowman's answer as principle, but I manage to just unload projects from solution from Solution Explorer directly (mark all projects, right click, and select Unload Project), and then run the
msbuild *.sln /t:Clean,Rebuild
from Visual Studio Command Prompt. When finished, just reload projects in Solution Explorer.
It saves me minutes (!) when I need to rebuild solution.
I have MSbuild task like this to sign all the output modules of our project.
<SignFile Condition="Exists('$(OutputPath)\%(FilesToSign.identity)')"
CertificateThumbprint="$(THUMBPRINT)"
SigningTarget="$(OutputPath)\%(FilesToSign.identity)"
TimestampUrl="http://timestamp.verisign.com/scripts/timestamp.dll" />
It takes quite a while (10 minutes or more) when I have many files. It is possible to run stuff in parallel or in other ways speed it up. (I am trying to sign more than 100 files.. )
Another way of speeding up the signing is to remove the TimeStampUrl parameter. It may not be good enough for release build (to not have a time stamp on the signature), but it is good enough for a development build.
And it speeds up the signing process with 80-90%.
The only way to do parallel build with MsBuild is to have different instances of msbuild, thus different project files, I don't think that's recommended here. You cannot do task or target in parallels, yet you can build project in parallel (but you can create several project files with one target in each). You may have precision here : How to run tasks in parallel in MSBuild .
Moreover, I think you will be limited by your disk access speed and not by your memory.
I don't know the SignFile task enough to give advice on how optimize it, though, sorry.
Using VB 2008
When I press the F5 or Start Debugging it does a rebuild even when I have made no changes since the last time. Where is the setting to tell it to only do a rebuild if there are changes?
F5 should a build and not rebuild, are you sure it's a rebuild? Even you do not make any changes, a 'pseudo' build is still executed, and should be significant faster than a normal build or rebuild.
EDIT:
My definition of a 'pseudo' build is to check for need to build and/or making sure all files required for debugging are present (e.g. pdb files)
In my installation, F5 (Start Debugging) only builds when changes have been made. This includes changes that don't actually effect the code (like modifying comments). If I do F5, close the program, and push F5 again (without changing anything), no rebuild takes place. Is there something I'm missing?
As other have mentioned, Visual Studio only rebuilds what it thinks needs rebuilding.
My advice is to check what it actually builds, to see what made the build system think it was out-of-date. I've often seen this issue when, e.g., a custom build step was used, and the output of the step was specificed incorrectly. So VS is expecting a built file (because you told it it would be there), and since the built file is not there, it restarts that specific build step, along with all the projects that depend on the project containing the build step.
This is just one example. It usually boils down to an expected generated file that gets moved or is missing.
If this does not help, maybe a build log would help identifying your issue in more depth.