Here is how I was told to deploy my ASP.net(mostly intranet) website\program\application to the production web server in my company.

  1. Change necessary settings in web.config for production web server.
  2. Copy EVERYTHING of my source codes, then paste in the designated virtual directory\folder in the web server.

As far as I know, I should be:

  1. using the Publish.. or Publish Web Site in Visual Studio to generate the codes.
  2. Copy the generated codes to the designated virtual directory\folder in the web server.

Which is a better deploy method?

What are the pros & cons of these two deploy methods?

Is there a standard(for poor man or cheap) way to do this?

  • 2
    IIS doesn't need your .cs or .vb files, it just needs the compiled output (dll files) and the views/static files. Publish within Visual Studio to the location of the virtual directory on the server.
    – neilsimp1
    Jul 21, 2016 at 13:29
  • 2
    Please please please use the publish functionality. Manually copy pasting to the server is terribly error prone.
    – RubberDuck
    Jul 21, 2016 at 13:40
  • 2
    There are many ways to deploy your web application, but the method you were told is probably the worst possible way.
    – Eric King
    Jul 22, 2016 at 2:31

1 Answer 1


From my painful experience, the more of deployment process is being done manually, the bigger trouble you'll get into. And both your current steps require heavy manual effort. Here are my recommendations:

1. Use VS Publish functionality as your bare minimum

First step toward having automated deployment process is, as you are aware of, using Publish functionality in Visual Studio. With the right setup of XML transformation, this functionality will handle the changes you need to happen on web.config (and other XML-based config files).

Ideally, if you have access to production server, you can target the Publish to the production server website. This will do the copy/paste for you. Otherwise, target to an isolated Folder in your system (that you will never mistake it with the source code folder).

2. Employ Continuous Integration (CI) and Continuous Deployment (CD)

This may be overkill for small projects that are mainly maintained by sole developer. But CI/CD is the way to go if your project evolves to a monster. Here are the indicators to start using CI/CD:

  • Your project and the team working on it become big enough that you literally cannot manual test all aspect of the website every time new changes are introduced => You need automated test, and need it done every single time someone commits a change.

  • You now have multiple environments to deploy to (dev, staging, UAT, production, you name it). While creating Publish profile for each of them is still feasible, knowing when you should deploy to a specific environment will become tricky (say, only deploy to production if all your tests are passed in other environments, and your boss - aka your customer - is happy with UAT).

  • You need the ability of rolling back your deployment. See how cool it is? CD could literally save you hours when something goes south with your newest deployment with just one button click.

  • You want to keep sensitive configuration data from checking in to source control (say you don't want to expose connection string to your production DB to a newly-hired junior dev). The workflow with VS Publish + XML transformation makes it harder to achieve this.

There are plenty of CI/CD tools for you to start with, some of them are FREE. Currently I'm happy with TeamCity for CI and Octopus Deploy for CD (both are free for small teams).

  • 2
    Actually, you can publish a package using the same wizard tool. The package gets placed in a staging area and then installed via command line. Protip: use config parameters instead of config transform. It keeps all production connections completely out of local dev environment. Super easy to pass off to OPs for deploy too. Well worth the pain of setting up.
    – RubberDuck
    Jul 22, 2016 at 3:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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