46

Our product's solution has more than 100+ projects (500+ksloc of production code). Most of them are C# projects but we also have few using C++/CLI to bridge communication with native code.

Rebuilding the whole solution takes several minutes. That's fine. If I want to rebuilt the solution I expect that it will really take some time. What is not fine is time needed to build solution after full rebuild. Imagine I used full rebuild and now without doing any changes to to the solution I press Build (F6 or Ctrl+Shift+B). Why it takes 35s if there was no change? In output I see that it started "building" of each project - it doesn't perform real build but it does something which consumes significant amount of time.

That 35s delay is pain in the ass. Yes I can improve the time by not using build solution but only build project (Shift+F6). If I run build project on particular test project I'm currently working on it will take "only" 8+s. It requires me to run project build on correct project (the test project to ensure dependent tested code is build as well). At least ReSharper test runner correctly recognizes that only this single project must be build and rerunning test usually contains only 8+s compilation. My current coding Kata is: don't touch Ctrl+Shift+B.

The test project build will take 8s even if I don't do any changes. The reason why it takes 8s is because it also "builds" dependencies = in my case it "builds" more than 20 projects but I made changes only to unit test or single dependency! I don't want it to touch other projects.

Is there a way to simply tell VS to build only projects where some changes were done and projects which are dependent on changed ones (preferably this part as another build option)? I worry you will tell me that it is exactly what VS is doing but in MS way ...

I want to improve my TDD experience and reduce the time of compilation (in TDD the compilation can happen twice per minute).

To make this even more frustrated I'm working in a team where most of developers used to work on Java projects prior to joining this one. So you can imagine how they are pissed off when they must use VS in contrast to full incremental compilation in Java. I don't require incremental compilation of classes. I expect working incremental compilation of solutions. Especially in product like VS 2010 Ultimate which costs several thousands dollars.

I really don't want to get answers like:

  • Make a separate solution
  • Unload projects you don't need
  • etc.

I can read those answers here. Those are not acceptable solutions. We're not paying for VS to do such compromises.

Community
  • 1
  • 1
Ladislav Mrnka
  • 360,892
  • 59
  • 660
  • 670
  • 4
    I think this is very subjective...you have *A LOT* of code, nobody knows what spec machines you have, do you have SSDs? Blah blah blah... VS2010 already does everything it possibly can not to recompile code that hasn't changed, so I don't think you will get answers much different to the answers you *don't* want to hear. Why don't you test your compilation times on a super high-spec machine (if you can get one) and see if it helps? Resharper also does not help the speed of the IDE at all. – Strelok Dec 06 '11 at 10:52
  • @Strelok: What is super hi-spec? VS is only 32-bit app so memory doesn't matter (I have 8GB), it doesn't use full power of multi core processors (I'm using i7 with HT). Yes SSD can help but IMHO there should not be almost any access to unchanged projects and no access to projects unrelated to my changes because that is context information which VS should know from my current working session. – Ladislav Mrnka Dec 06 '11 at 11:07
  • 2
    Well, these are assumptions we can make, which does not necessarily mean are true. I have used VS2010 with and SSD before and I have noticed considerable improvements in build times on large solutions. Maybe worth watching IO performance counters (or other tools) during a build cycle to confirm if it's definitely IO. You are right on the other points about hardware. Point is obviously you already have a fine tuned solution. It's just you have a lot of code. Have you also tried builds without ReSharper installed? – Strelok Dec 06 '11 at 11:13
  • It's just there is a lot of other factors that can impact your build times. Virus scanners, plugins, lo spec hardware, bloated Windows install etc. I think you should try this on a brand new install of Windows with no extra software and in a clean install of VS2010 with no plugins etc. If you are still experiencing slow build times you've probably hit VS's speed limit, if build times improve then I guess there is *something* you can do about the environment. – Strelok Dec 06 '11 at 11:17
  • 8
    @Ladislav: You're saying that "there should not be almost any access to unchanged projects and no access to projects unrelated to my changes", but let’s look at it from VS’ “point of view”. VS _must_ determine if projects have changed, and in order to do so it needs to scan all the source files to analyse their last modification times (at least). It must do this, and no internal context information can help: files can be changed externally in the first place. Now, if you have 100+ projects then I assume you have thousands of files in hundreds of folders, and it _does_ take time to scan them. – Igor Korkhov Dec 06 '11 at 12:22
  • 2
    If you want to improve you TDD experience then you probably would want to look at NCrunch project: http://www.ncrunch.net/. NCrunch (re)builds and runs your code and tests in background while you type, so you don't have to stop coding, build your app and only after that run tests. – Igor Korkhov Dec 06 '11 at 12:27
  • @Igor: That is a good point! So I'm looking for a way how to turn this check off because my files are not changed outside of VS so I don't need to pay the price of checking in every build. – Ladislav Mrnka Dec 06 '11 at 13:32
  • 1
    I've just installed NCrunch and I have to say it's really cool. It definitely helps with compile speed and the immediate code coverage is a nice feature. – Wouter de Kort Dec 06 '11 at 15:00
  • I have a similar setup and my unchanged C# projects are basically skipped with minimal checking, but my C++/CLI projects are always recompiled. Is this the problem you are having? – Eric Nicholson Dec 06 '11 at 15:54

7 Answers7

12

By default Visual Studio will always perform build of every project in your solutuion when you run a single project. Even if that project doesn't depend on every other project in your solution.

Go to Tools | Options | Projects and Solutions | Build and Run and check the box "Only build startup projects and dependencies on Run". Since now when run your project (F5 key), Visual Studio will only build your startup project and the those projects in your solution that it depends on.

Dmitriy Konovalov
  • 1,777
  • 14
  • 14
  • 3
    This is not what I'm asking for. I don't Run the solution. I run test and this configuration doesn't affect this behavior. Even if it does it will result in the same result as building just a test project. – Ladislav Mrnka Dec 06 '11 at 16:10
8

Is there a way to simply tell VS to build only projects where some changes were done and projects which are dependent on changed ones (preferably this part as another build option)? I worry you will tell me that it is exactly what VS is doing but in MS way ...

Not really (you understand it already).

You are talking about a "build system". MSVS is not that. It is an IDE, which happens to permit you to organize your assets into projects-and-solutions, and yes, to "build". But, it is not a build system. It will never be a build system (long story, but a very different technology is required).

In contrast, MSVS is an IDE for accelerated iterative development, including the "debugging" cycle (e.g., "step-into" and "step-over" in the debbugger during system run). That's where MSVS "shines".

It does not, and will never, "shine" as a build system. That's not what it was created to do. And, this will likely never change (long story, even Microsoft will likely agree).

I'm not trying to be cute, and I sincerely apologize for delivering this news. This answer hurts me too.

I expect working incremental compilation of solutions. Especially in product like VS 2010 Ultimate which costs several thousands dollars.

MSVS is an IDE for interactive debugging/development, and not a build system (see above). So, you are measuring it in a product scenario for which it was not designed, and in which it will likely never function as you desire.

I really don't want to get answers like:

  • Make a separate solution
  • Unload projects you don't need
  • etc.

I can read those answers . Those are not acceptable solutions. We're not paying for VS to do such compromises.

Your expectations are reasonable. I want them too. However, MSVS is not a product that will ever deliver that.

Again, I'm not trying to be "cute". If you are willing to invest in a "build system", you may find value in using something like CMake to manage your configurations and export Makefiles (or something) to perform your "real" builds, but to also "export" *.vcproj and *.sln files for when you want to do work iteratively and interactively within the MSVS IDE.

EDIT: Rather, what you want is a SSD (solid-state-disk) for your build workspace to get a 10x improvement-in-speed, or a RAM disk for a 100x improvement-in-speed for builds (not kidding, 64MB RAM on an LGA2011 socket gives you a 32MB RAM disk, which is what we use.)

charley
  • 5,913
  • 1
  • 33
  • 58
  • This is something I recognized today when reading answers from others. In short I expected that expensive product like VS should have some meaningful integration with build engine running on behind (MSBuild) but it appears there is none - it just run it without sharing any contextual information. What I only want is a system where changing few lines in single file will not result in delay caused by checking thousands of files on disk (as described in some comment). – Ladislav Mrnka Dec 06 '11 at 16:42
  • My collegue tested RAM disk today and he got only 2x speed improvement (strange). I will make some tests with SSD on my home PC. – Ladislav Mrnka Dec 06 '11 at 22:17
  • @Ladislav -- 2x?? Ouch. We're still configuring ours, so I don't have solid benchmarks yet, but we're trying (1) RAM disk for only intermediates (*.obj/*.pdb/*.dll/*.exe/etc.) and (2) For the whole workspace (including all source). From reviews on the web, configuration and the RAM disk software used can make a big difference (we are currently only trying to work with Gillisoft, but there appear to be a number of good ones available). – charley Dec 06 '11 at 22:59
  • @Ladislav: on my work PC McAffee's on-access scan significantly levels down all the RAM disk speed improvement. Maybe you would like to look at your anti-virus software configuration (if you have it installed, of course) – Igor Korkhov Dec 07 '11 at 11:23
4

One things you can do is to break your app into small solutions, each one being a cohesive part. Build each solution separately. Have each solution use the outputs of the solutions it depends on, rather than using the source code.

This will allow for shorter feedback cycles for each component

EDIT: Modified Solution

Additionally, you will create an integrative build that rather than getting all of the sources, compiling and testing, it will get the binary build products of the component CI builds. This integrative build should be triggered to run after every successful component build.

This build should be the binary equivalent of a complete build (which you still should build every night), but will take considerably less time to run, because it triggers after a component increment and doesn't need to compile or get any sources.

Moreover, if you use an enterprise grade build system that supports the concept of distributing your builds among multiple agents, you will be able to scale your efforts and shorten your complete CI cycle to the amount of time it takes to build the longest component, and test the integrative suite (at most).

Hope this helps.

Assaf Stone
  • 6,309
  • 1
  • 34
  • 43
  • This will allow me getting shorter local feedback cycles but it will postpone full feedback. That is the reason why I don't like it. We have multiple partial solutions and single All solution. Most developers is using All simply because using only partial solution very often results in failed build on CI server - there is large shared core containing a lot of projects which must be part of all partial solutions - that is the reason why it doesn't work. It can be our failure but it is not related to the main point of my question. IMHO it is too late to find build failure on CI server. – Ladislav Mrnka Dec 06 '11 at 16:08
  • Thank you, this solves the problem, Delphi was smart enough to do this without having to have separate solutions. – jimjim Sep 18 '16 at 23:19
2

Weighing a bit late on this, but have you considered having different build configurations?

You can tell visual studio not to build certain projects depending on the build configuration.

The developer could simply select the configuration relevant for the project their working on.

Chris Haines
  • 6,445
  • 5
  • 49
  • 62
1

Pretty ancient thread, but I can say I was suffering from a smaller version of the same thing and I upgraded to Visual Studio 2012 and the problems seems to have finally been fixed. The RedGate .NET Demon solution mentioned above also seems to work pretty well so far.

Wade Hatler
  • 1,785
  • 20
  • 18
0

This is an old problem.

Use parallel build and SSD . See here (I think - quick google): http://www.hanselman.com/blog/HackParallelMSBuildsFromWithinTheVisualStudioIDE.aspx

Sentinel
  • 3,582
  • 1
  • 30
  • 44
0

I found a tool which does mostly what I want (and even more): RedGate .NET Demon. It is probably still the first version because I encountered few issues in our big solution (problems with C++ projects, problems with switching build targets and few others) but I really like it so far. I especially like the way how it tries to track changed files in VS IDE and rebuilds only affected projects.

Edit: .NET Demon has been retired as it should not be needed for VS 2015. It still works with previous versions.

Ladislav Mrnka
  • 360,892
  • 59
  • 660
  • 670