Kyle Bailey invited some criticism in his article, so I'm going to deliver it.  You can read the original article HERE, but to sum up:

"The basic idea Donald described was thus: Just because you build your application one way in Visual Studio during development, doesn't mean you need to build your releases the same way. Especially if you are using NAnt to create your releases because then you can do it however you like."

I use nant too.  But I can tell you, I do NOT make my nant build different between production, staging and development the way they're suggesting.  I point my nant build to my solution file and have everything run off that, using the <MSBUILD> task.

The reason I don't do this is because i've been burned by something similar to this in the past.  When i first started using vs.net 2005 and projectless websites, i started looking at the different build options and also at web deployment projects which are just friendly MSBuild wrappers.   Although I don't like projectless websites (a topic for another post perhaps) everything went more or less fine with my new VS.NET 2005 project, until I went to deploy.  Then MSBuild crapped a log.  The site wouldn't compile.

After figuring out how to get msbuild and vs.net to show me more explicit error messages other than "aspnet compiler failed' or some such ***, i found out the problem was due to 2 classes with the same name.  Under normal development circumstances using projectless websites, 2 classes (or pages) can have the same name without any problems.  This is because each page gets compiled as its own assembly.  However, when I was deploying, i wanted everything in one assembly.  This caused MS Build to fail, because 2 classes with the same name in the same assembly isn't allowed.

So i learned early on not to create any surprises for myself when it came to staging and production deployments.  Make everything as similar as possible, so you catch issues early on.

That being said, much of my problems with that had to do with projectless websites and third party code that had the duplicate classes.  I use web application projects now and I'm a lot happier.  I also use nant instead of web deployment projects, and nant is probably a lot more flexible.  But I'm still hesitant to differentiate my development and other builds because I don't want any surprises.

There's perhaps one other reason not to do what Kyle and his friend Donald are suggesting--its more work.  Remember the D.R.Y. principle?  Duplicating anything in IT is bad.    Under Kyle's methodology, It sounds like if i add a class to my vs.net solution, i then have to add it to my nant build file.  Same for including or excluding references.  This just sounds like additional maintenance pain caused by duplication. 

Sorry Hillbilly, you lost me on this one. 

Read the complete post at http://dotnettricks.com/blogs/craigbowesblog/archive/2008/02/11/704.aspx