views:

140

answers:

8

Speaking about compiled languages (c# in my case) I think that problem would always remain, no matter how performant your develop machine is. Build time could be more or less depending on concrete environment, but often it's enough to make your attention wanna move from your task to something else like stackoverflow, youtube, twitter etc. and it's just very annoying.

I'm happy for java developers because of Java's dynamic class loading, but what can .net (and others) developers do to make build process less painful and obtrusive?

+1  A: 

The remark in your question about one's attention wandering off-task reminded me of this Joel on Software post.

So investing in solid-state disks (since I'm assuming you're talking about the build process on a dev box while you're developing and debugging) could help.

Besides, making your computer faster in general can't hurt, right? :)

djacobson
+4  A: 

We use multiple build configurations to trade-off between speed and a comprehensive build.

A full build does time-consuming things like FX cop analysis, ASP.NET compilation, all unit test projects, Entity Framework view pre-generation, etc.

A "fast build" typically takes just a few seconds and those the bare minimum needed to get the project running.

Developers switch between the full build and the fast build throughout their workflow, as needed.

Craig Stuntz
+1  A: 

If you're using ASP.NET, here are some great tips. I think There are some tips there for non ASP.NET solutions as well. Anyhow it helped us a lot, especially #3 on the list.

Oren A
thanks, looks promising
kilonet
+1  A: 

In addition to many of the other suggestions to get a faster machine, remove unnecessary projects from your solution, etc, consider Visual Studio 2010 + a multicore machine. VS2010 can take advantage of all of your cores when doing a build. Check out this thread for more on how to set that up.

Steve Danner
I don't know if VS2010 takes advantage of all cores, but the build is painfully slow on my machine for WPF projects, even relatively small ones (Core Duo 3GHz and 4GB RAM).
Thomas Levesque
+3  A: 

Don't the class files have to be build as well? Wouldn't that just put the workload to runtime in contrast to compile time? That's not really a difference isn't it? The bigger software grows, naturally, the longer it takes to build it, depending on the machine and not on the language or framework - this is the tradeoff for things like strong typing, interpreted byte code (or binary code depending on the language/compiler) instead of interpreted source code at each run (as you have with php and python etc). I don't think java improves things much, there will a timeframe you have to build your application in.

I think in comparision to C and C++ both C# and java have improved immensely on the account of compile time.

Just use the time for slacking off:

Compiling

source

Femaref
Superior picture :)
Nick Martyshchenko
+1  A: 

Some things to try:

  1. Defragment the drive containing your source code

  2. Exclude your source code folders from the virus scanner

  3. Exclude your source code folders from the Windows Search indexer

  4. Disable any Visual Studio extensions that you are not using

Nathan Rivera
+1  A: 

Are you doing a rebuild all every time or do you have everything in the same assembly? I'm working with quite large projects and my build time isn't that high. I got several assemblies and I only modify a few each time I do changes to the project.

If you find yourself modifying assemblies all over the place, you might try to refactor your code structure. Or maybe you haven't taken yourself time to do unit tests? They do not only help you with the testing, but to get better code structure (hard to test apps with lousy design).

Another alternative is to use tools that speed up builds, for instance: http://www.xoreax.com/

jgauffin
A: 

I've worked on some very large C# projects and have rarely seen Debug build times exceed 2 minutes.

What generally sucks time are things like static analysis (e.g. fxcop), unit tests, code signing (if using a code sign service), etc. The easiest way to keep these under control is to either limit them to Release builds or to have a separate build definition for 'Full Build' and exclude these steps from your Debug and Release builds.

If these aren't your problems, look to your computer performance as others have said. Fragmentation, slow build disks, anti-virus, etc.

Jay