I actually use this more simple model as well , 90% of the time.

This post:
http://groups.google.com/group/microsoft.public.dotnet.framework/msg/1f2a4acce0d9c77c

shows a trick I use to get release-build stuff, without going through the
GUI.  via a .bat file.
But its essentially the same thing.  Build in release mode.....
I actually never copy my web.config file....to a staging or production
server....you might even include web.config in the exclude.txt file.  (This
is how I ensure the debug=false setting stays correct).

............

But again, this is the simple approach...there are many steps between simple
and super-duper MSBuild level...so throw out some goals.

How do you catch things like:

1. Connection strings are different for test and production.
2. Some page uses a 3rd party control that isn't installed on the production
server.
3. Some code uses an assembly that isn't present on the production server
(e.g. the zip library from vjslib.dll).
4. Firewall issues (if test is inside the firewall and production is in
DMZ).

We've tried to mitigate these problems by using the same server for "test"
and "production" (just a different web site on the same server) and by never
copying web.config (we make changes manually, if necessary).

I'm just wondering if there is a better way. I guess I'm also saying that
it's not always as easy as "1, 2, 3".