Asp.Net MVC Multi Area Projects and Intellisense

If your MVC project is divided in to multiple area projects and if you are using portable areas feature of MVCContrib, and if the view pages are stronly typed, intellisense on the view pages might not work.

Only way I was able to make this work is

a. Copy the main web.config file in to the area project

b. Copy the Views\Web.Config in to the areas project under views folder

c. Do not select 'Copy Local' option on System.Web.MVC dll.

Using TestDriven.Net and NCover to boost your team to write more tests

Having a large number of unit tests and sizable number of integrations tests is essential for maintaining a software project or product.  Apart from the quality of those tests, the quantity is some indication that the teams are in the right direction.

I see the following clear benefits of tests among many.

• If your working code is the truth, tests are the validators of that truth.  Tests are the code's knowledge base.


• They take out the fear of unknown.  This encourage the developers to refactor the code and improve it instead of merely maitaining it.


• Tests essentially improve the design of the code


• Tests helps new developers to come up to speed with the code base quickly

TestDriven.Net is a visual studio plugin that makes it super easy to run the tests right from the IDE.  This plugin integrates well with NUnit GUI and also NCover.

NCover is a code coverage tool.  It shows how much of your source code is covered by the tests.  Once you run the tests using NCover, it produces a report of which parts of the source code is not covered by the tests in percentages.

I found that these numbers play an important role in the developer psyche.  Once developers looks at these numbers, and know that how much of their code is not being tested at all, they can't resist from writing more tests.  I have seen this happening all the time. If stackoverflow.com's success is any proof that developers like numbers, scores, this makes complete sense.

Declare a target coverage percentage to the team and announce which parts of the code reached the target in the daily team meetings.  Like every other thing in development large number of poorly written tests could become a maintenance headache.  Once your team gets in to the track of writing tests, it is very important to review the tests.

Happy testing!

MVC Portable Areas and WebForms

MvcContrib project has a neat little feature called portable areas.  This allows us to develop features as independent units of work in asp.net mvc.

Eric Hester wrote a detailed post on how to use areas in an MVC project.  Jeffery Palermo wrote on how to use portable areas in a webforms project.

Portable areas projects stores all the views in the assembly as enbedded resources.  Normally asp.net runtime look for the page in the file system.  We can change this behavior by making the following call in the application start event of the global.asax file.

HostingEnvironment.RegisterVirtualPathProvider (YourVirtualPathProvider);

Portable areas feature in MVCContrib simply does that.  MvcContrib profject supplies a VirtualPathProvider called AssemblyResourceProvider.

However the above call will fail quietly if your website is precompiled.   This behavior is documented in an MSDN article.  So in order to use the portable areas in your webforms project, you should not use precompile option in the website project.

Migrating large asp sites to asp.net - website project

In web forms world of asp.net , visual studio offers two options. WebSite projects and WebApplication projects.   If you are starting a green field project and choose to take web forms route,  website projects are definitely not a good option, especially if the site size is large.   But if the site is being migrated from legacy asp site, it is better to stick with website project.  You are not going to benefit a lot from web  application project, if the individual asp.net pages (not in code behind) are going to contain most of the code.

Following are some of my observations from such an effort.

• Patching gets simpler.   The quickest way to patch an asp page is just copying modified page on to server.   As legacy site is mostly likely contains code a markup combined, this option helps to maintain the new site until these concerns are separated.
  

• Site can be precompiled to check for the asp.net page errors.  In web application option, if the code is in asp.net page,  vs.net is not going to compile asp.net pages.   So there is no way to know if there is a problem with a page until runtime.
  

• Visual Studio crashes every time if you try to convert a large site in to a web application project.  Your web deployment projects won't finish without crashing.  This instability suggests that you should better stick to website project.
  

• Every time you touch the bin folder or web.config or user controls, app domain gets recycled.  This kicks users out.  You should be able to mitigate this a little by choosing some kind of persistent session option.
  

• If you choose to deploy precompiled site, with every patch you will be deploying more dlls than necessary.  This is because every refereced dll is going to produce a new version of the dll that is different from the already deployed version.
  

• Visual studio suffers from huge performance issues, especially when the site is large.  Combined with Resharper, it feels like being in a hell to use the IDE to make small changes.  If you have automated integration tests, then better not to use Visual Studio for simple changes.
  

• You want to turn the 'Build Website' option off, else you will waiting for the compiler to come back for the most part of the work, when ever you modify a sub project item that compiles in to your site's bin.  It is better to defer the build site option to the build server.
  

• Your builds are going to be slow.   Every time if some one checks in the code you need to Clean, Build, PreCompile the while site.  Precompile task runs really slow as it has to compile each page in to its own dll and copy every thing in to new directory.  You can speed this a little with in-place precompilation.
  

• Deploying involves two steps.

Step 1:    Clean, Build, PreCompile -> to make sure that build is still ok

Step 2:     Clean, Build, Copy web files, copy bin files, copy environment specific config files,  -> if you are not deploying the precompiled site

Copy the precompile outputs, copy environment specific files -> if you are deploying precompiled site

• You might not be able to use the built-in web server for testing the application, again due the size of the site.