How to setup ASP.Net MVC solution for quickest build time

Question

I want to find the best setup for ASP.Net MVC projects to get the quickest code-build-run process in Visual Studio.

How can you set up your solution to achieve near zero second build times for small incremental changes?

If you have a test project, with dependencies on other projects in your solution, a build of the test project will still process the other projects even if they have not changed.
I'm don't think it is entirely rebuilding these projects but it is certainly processing them. When doing TDD you want an near zero second build time for your small incremental changes, not a 20 - 30 second delay.

Currently my approach is to reference the dll of a dependent project instead of referencing the project itself, but this has the side effect of requiring me to build these projects independently should I need to make a change there, then build my test project.

One small tip, if you use PostSharp, you can add the Conditional Compilation symbol SKIPPOSTSHARP to avoid rebuilding the aspects in your projects during unit testing. This works best if you create a separate build configuration for unit testing.

Answer 1

Here's how you could structure your projects in the solution:

• YourApp.BusinessLogic : class library containing controllers and other logic (this could reference other assemblies)
• YourApp : ASP.NET MVC web application referencing YourApp.BusinessLogic and containing only views and static resources such as images and javascript
• YourApp.BusinessLogic.Tests : unit tests

Then in the configuration properties of the solution you may uncheck the Build action for the unit tests project. This will decrease the time between you press Ctrl+F5 and you see your application appearing in the web browser.

Answer 2

I don't think "code-build-run" is any way a tenet of TDD.

You don't need zero-second build times -- that is an unreasonable expectation -- 5 - 10 seconds is great.

You're not running tests after every tiny incremental change. Write a group of tests around the interface for a new class (a controller, say, or a library class that will implement business logic). Create a skeleton of the class -- the smallest compilable version of the class. Run tests -- all should fail. Implement the basic logic of the class. Run tests. Work on the failing code until all tests pass. Refactor the class. Run tests.

Here you've built the solution a few times, but you've only waited for the builds a total of 30 seconds. Your ratio of build time to coding time is completely negligible.

Answer 3

I like Onion architecture.

Solution should have ~3 projects only =>

• Core
• Infrastructure
• UI

Put 2 more projects (or 1 and use something like nUnit categories to separate tests) =>

• UnitTests
• IntegrationTests

It's hard to trim down more. <= 5 projects aren't bad. And yeah - avoid project references.

Unloading unnecessary projects through VS might help too.

And most importantly - make sure your pc is not clogged up. :)

---

Anyway - that's just another trade off. In contrast to strongly typed languages - dynamic languages are more dependent on tests but it's faster and easier to write them.

---

Small tip - instead of rebuilding whole solution, rebuild selection only (Tools=>Options=>Keyboard=>Build.RebuildSelection). Map it to ctrl+shift+b. Original map remap to ctrl+shift+alt+b.

Answer 4

One way you can cut down on build times is to create different build configurations that suit your needs and remove specific projects from being built.

For example, I have Debug, Staging, Production, and Unit Test as my configurations. The Debug build does not build my Web Deployment project or my Unit Test project. That cuts down on the build time.