Is there an instrument that can find me a place in my project which takes so long to build? Like performance profiler, but for the build process of Visual Studio.
P.S. I tried profiling my Visual Studio during build with another instance of VS, but I didn't get obvious results.
Tools -> Options -> Projects and Solutions -> Build and Run
There you can change the
MSBUild project build output verbosity
settings
When on normal level it will give timings for each project, so this could be used to see what is causing the slow down. (in the Output window)
On a higher level you will see even more detail of what is going on during a compile.
I got better results with http://msbuildprofiler.codeplex.com/ then compile my solution in a msbuild prompt
MSBuild.exe MySolution.sln /t:rebuild /l:MSBuildProfileLogger,MSBuildProfiler,Version=1.0.1.0,Culture=neutral,PublicKeyToken=09544254e89d148c
Just be careful to run rebuild target (/t:rebuild) otherwise you get completely different results second time you run it.
I think $1 donation is good price :)
Related
I've been working on a big legacy C++ solution (.sln) using Visual Studio as its build system. The /MP flag is enabled for every projects in the solution in order to build the source files (.cpp) in parallel. The option maximum number of parallel project builds is also set in order to build the projects (.vcxproj) in parallel. I'm using the Parallel Builds Monitor Visual Studio extension to be sure that the projects are built in parallel and to see how much time it takes for each project.
The following image is the result of rebuilding the whole solution. The projects are built in parallel indeed, but there's one project (A.vcxproj) that catches my attention. It shows that it takes 13m16s to build that project.
However, it doesn't seem right, so I rebuild only that project, and it only takes 1m25s, as you can see in the image below.
My question is: Why does the thread that builds A.vcxproj have the strange behavior? It seems to me that the thread just picks up A.vcxproj, starts building the project, and for some reason, it switches to another project, and then it comes back to A.vcxproj at some point later, hence the long build time (13m16s). Please let me know if I'm understanding it completely wrong!
I have a solution called MainWindow.vs2015.sln for my Application. This has nearly 100 Projects and it builds perfectly in Visual Studio 2015. When I build the solution from the command line using devenv, it also works perfectly and there are no errors.
However, when I build from the command line, and then open Visual Studio 2015 and build it again, expecting an almost instantaneous build as I had already built from the command line, it builds the whole thing all over again and I am sat there for up to nearly 30 mins waiting for something to build all over again.
Is there some kind of difference between the devenv command and Visual Studio builds?
P.S I have also MSBuild as well as devenv and have had the same problem.
devenv MainWindow.vs2015.sln /Build "Debug ALL"
What's your project type? VB.net, C# or C++?
For .net projects:
If we create a new VS2015 C# project in command-line, build it in Debug+x64 combination. After that when open the project in IDE and build it, it will display Up-To-Date, and won't compile and build again since nothing changes.
So if you meet the build twice issue in C# projects, set the Build Output verbosity to Detailed or higher in VS to see detailed info about the build process.
After that, when you again meet this issue, trying reading the very first of the log to see the reason why VS builds it again! Check if you have some files missing or set as Copy Always like this.
For C++ projects:
If you're in a solution with many C++ projects in it. I'm afraid the answer could be negative. I test it in VS2015 C++ projects and I can reproduce same issue. I found if we create a C++ project, build it in command-line and then VS. VS will consider it not to be up-to-date and try to build it again...
Something interesting is if we build it not by command-line, instead we build it twice in VS, VS can recognize it's update-to-date and won't waste time to build it the second time.
So I suggest you could avoid building it in command-line before building in VS. Cause there's no advantage that we build the project using two ways while we don't do actual modify to the source files. Also, since there's something that can be improved about the Up-To-Date check in VS for C++ projects, you can post a feature request in DC and you can get help from the Product Team there.
In addition: Please make sure the Configuration+Platform you use to build solution in command-line are the same when you build in VS IDE.
Hope it makes some help :)
I have a question regarding the difference I have noticed when building a solution file using MSBuild from command line and when doing it inside Visual Studio 2013 Update 4. The solution file I am using contains a lot of projects.
Case: Using MSBuild
After successfully building the solution file, if I try to build it again, MSBuild notifies me that the projects are up-to-date and it doesn't try to compile any source files, which is evidently the expected behavior. Nevertheless, it actually tries to execute or goes through the targets in the Build step trying to determine whether the Output files are out-of-date and this occurs for every project that is existent in the solution. Even though it doesn't build the solution again, the process of checking time stamps of files for each project actually takes quite a long time.
Case: Using Visual Studio
When doing it inside Visual Studio, after a successful build, if I try to build the solution again, then it automatically notifies me that the projects are up-to-date. It actually takes few seconds to return this output. Looking at the build output, I noticed Visual Studio doesn't really execute targets in the Build step to conclude that the projects are up-to-date. So I figured it must be using something different to check the statuses of the projects.
I really want to bridge the performance gap between these two "worlds". I would appreciate any help or hints in regards to how Visual Studio is performing this check or ways I could implement something similar in MSBuild.
Cheers!
When Visual Studio runs a build, it runs MSBuild to do the majority of the work. If you pass the .sln file to MSBuild, with appropriate Configuration and Platform properties, it will build your solution similarly to how Visual Studio would.
msbuild mysolution.sln /p:Configuration=Release /p:Platform="Any CPU"
However, there are differences: sometimes a build will error through MSBuild and not through Visual Studio, or vice-versa.
What parameters does Visual Studio pass into MSBuild to influence the process? Is there some way to see the parameters it's passing as a build is is executed?
Visual Studio does not execute MSBuild.exe, but hosts the build engine itself (by means of the Microsoft.Build.* assemblies) - at least that is the case for the default C# project system. Other languages, addins, packages, etc. might do it differently.
Actually, there was a post series on the Microsoft blogs about this, I'm trying to find them and update this answer.
UPDATE: Found it again. Look for the "MSBuild in Visual Studio" posts here.
Concerning your original question, this page might help you further. Also you could go to "Tools", "Options", "Projects and Solutions", "Build and Run" and increase the MSBuild output verbosity. With "Diagnostic" you should basically see every property that is set upon starting the build.
First off, you can run msbuild with the /v:diag argument to get diagnostic-level logging. This can really help in figuring out why a build is failing.
Otherwise, yes, if you use Process Monitor, you can monitor for process start events where you can see the specific command-line sent to the process.
Specifically:
Run Process Monitor
Filter » Filter...
Operation is Process Create » Add
Operation is Process Start » Add
OK
Run your build through VS and through command-line msbuild
See the command-line arguments in the Detail column
We would like to automatically log the time we spend building our project every day, while devving. Builds can be initiated by pressing f5, or runnning our n-unit tests with TestDriven.Net. We want the entire combined time of building, not just for one or 2 projects. We want to do this to compare the impact on productivity of a slow pc versus a fast pc.
Any ideas?
Update: I've investigated MSBuild loggers. This seems like it could work, but I can't figure out how to send parameters to MSBuild when we do an f5 build from VS.
VSCommands for Visual Studio 2010 and 2012 is available from Visual Studio Gallery can produce detailed build statistics in output window after the build is finished:
Tools + Options, Projects and Solutions, Build and Run. Change the MSBuild project build output verbosity setting to Normal. You'll get a Time Elapsed measurement at the end of the build. You can turn this setting to 11 to get a detailed breakdown. Build log output is automatically saved to the buildlog.htm file in the project's build directory.
The equivalent command line option is /verbosity:normal (/v:n). You can get output logged to a file with redirection or the /fileLogger option (/fl). Type msbuild /? to get a summary of these options, there are a bunch more obscure ways to log.
In the project output directory there is a project_name.log file with the line
"Time Elapsed 00:00:00.00"
You can parse this
You can use Tools | Options | Projects and Solutions | VC++ Project Settings | Build Timing to control whether that copy of Visual Studio includes timing in VC++ build output.
But that time and the Time Elapsed mentioned by #Martin appear in the Output window of Visual Studio when you do F5 builds and on the console when you do command line builds.
It sounds like you really want to collect the build times for several builds in one place. One place to start looking might be MSBuild Loggers.