There is no simple answer for that question. There are a millions of ways to do it, and the best one really depends on the company, your normal development habits, and application you are developing. So here are just some thoughts of what you need:
Source Control
It is imperative that you are running a good modern source control solution. MS Visual SourceSafe is NOT an example of one. A good free system is Subversion. Once you are running a source control system, you need to find out how to best working with branching and merging with that system. If using subversion, be sure to read the "Subversion Book". It is really well written and informative, and it has some good examples of how to manage releases.
Build Server
You need a build server to automate your builds, i.e. when someone commits changes to the source control repository, a new version is automatically build. The build system will take care of storing successful builds somewhere. This server should also automatically deploy successful build to a test/staging server. The build server will also take care of auto-incrementing the build no. A simple well-functioning free build server is cruisecontrol.net
Build output storage
You can store all build versions in the source control, but I would prefer to simply store them on a simple file server, in a folder structure where each build output is placed in a folder labeled after the build no. It is a souce control system, not a build output system.
Having complete history may not be that important if you are using, for example subversion, because here, you can always recreate the source code at any given point in time, making it possible to always be able to recreate a specific version. CVS cannot do this for example.
Deployment
I don't know exactly what is the best way to deploy to the production server. But I would consider something like this:
Every time the build server builds a release candidate, it will A: copy the production database to the staging server, B: Deploy the release candidate to the staging server.
That way, you will always test the release candidate against production data. If you have any updates the the actual database schema, there should exists as SQL change scripts that are applied to the database on the staging server as well, so the actual change scripts are tested.
When the release candidate has been tested on the staging server, the same mechanisms you used for deploying to the staging server should naturally be used to deploy to the production server. So the deployment is fully automated, and no room for human error. The build server could also be used for this.
Delpoying a web application is often just copying the files to a file share, or uploading through FTP. I wouldn't create an installer for it.
But these are just my general thoughts on release management of asp.net applications. You really need to consider the needs of your own application and your own company.