Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I have recently been moving away from ASP.NET Websites in favor of Web Applications. More specifically I have recently been picking up MVC as an alternative to developing ASP.NET Forms websites.

Something that I find highly frustrating is the constant build->change->re-build process when testing small changes to compiled code. I find myself 'bundling' several changes between builds just to avoid waiting 20-25 seconds for Visual Studio to crunch it's way through the compilation process. I created a clean MVC 4 project from the VS template and timed the build after making a single line code change, it took 19 seconds.

When making a change in the code-behind in an ASP.NET website I've always found that the page is seemingly re-compiled on the fly when you next hit the page. This would seem to me to be a better environment for web development rather than VS forcing an entire rebuild after every small code change.

In the past I have enjoyed the luxury of making a change, hitting refresh in the browser, and waiting 1-2 seconds for my result. Is this achievable with web applications built using Visual Studio?

share|improve this question

2 Answers 2

You can edit your MVC views while the site is running. The code for controllers and everything in between must be recompiled after a change. Did you write everything in the .aspx when using ASP.NET?

Anyway, 20 seconds is quite long for an incremental build after changing a single line of code (though it might depend on what you changed, it may cascade through a few assemblies). I'd try to address compilation speeds first. Why is it taking long? NuGet package restore? Copying lots of assemblies? Slow disk drive, CPU and low on memory?

On the other hand it sounds like your development practice is a bit suboptimal. You might want to employ test driven development, where you write a test to show what your intentions are, after which you start working on the implementation. This way you won't also have to wait for the development web server and the browser to start; you run the tests from Visual Studio.

share|improve this answer
    
I’ve added a brief paragraph to address your first question. I’d agree that moving towards a test driven approach is certainly the way forward and I understand that MVC makes this much easier. However, for the most part it seems that I’m waiting for the compile process to finish, so I would imagine I’d be faced with the same problem when running tests. –  Red Taz Dec 12 '13 at 13:25
up vote 1 down vote accepted

It seems I had overlooked the usefulness of the "Edit and Continue" option (Tools -> Options -> Debugging -> Edit and Continue) after struggling to get past the infernal dialog message:

Changes are not allowed in the following cases:

  • When the debugger has been attached to an already running process.
  • The code being debugged was optimized at build or run time.
  • The assembly being debugged is loaded as domain-neutral.
  • The assembly being debugged was loaded through reflection.

Despite having the option checked in VS options you have to enable it for each separate web application. In the Properties Page it's on the Web tab when you scroll right to the bottom "Enable Edit and Continue".

Making small changes using Edit and Continue isn't exactly the same as making code-behind changes to a Website project, however, it's far more palatable than restarting the app for every code change.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.