So after a few hours of trying to figure out how to publish my MVC project in Visual Studio 2012 to my web server running Microsoft Server 2012, I finally got it working.  I know there’s a lot of other blogs out there, but in order for me to get it working, I ended up having to take bits and pieces from multiple blogs and MSDN articles.  So, I decided to compile what I’ve learned and share here on my blog.

Preparing Visual Studio

What we’re discussing here is how to Publish a web application using Web Deploy in Visual Studio.  Upon right-clicking on the project, you’ll see something similar to the following drop-down.  Notice the fourth menu item is “Publish”.


Once you click on “Publish,” a dialog will appear.


Many hosting companies, including Azure, will provide a publishing profile.  If you are using a hosting company that does, in fact, provide this, click on “Import” and choose the publish settings file that has been provided.  For the purpose of this blog article, we’re wanting to create our own profile.  So, in the drop-down, choose “<New Profile…>” and type in a name for your new profile.  For this article, we’ll name the deployment profile “Testing”.  After typing in your profile name and clicking OK, you’ll be directed to entering the settings for the deployment profile.


Let’s walk through the settings.  It’s very important that you understand each of these options.

  1. Publish method – Here, we choose “Web Deploy” as that’s the purpose of this article.  There are other options should you choose to do so.  However, due to complexity of today’s viruses, Web Deploy/Web Deploy Package are definitely the safest for a production environment.
  2. Server – The Fully Qualified Domain Name (FQDN) of the server in which you wish to deploy your application.
  3. Site name – This is the name of the site (or application) in IIS on the remote server.  Typically, I name my sites by their URL so that they’re not confused.  If you are targeting an application in a virtual directory of your IIS site, you can target that application by entering the site name followed by a forward slash (“/”), then the app (i.e.
  4. User name – An authorized user for deploying the project to the server.  This can be a domain account, as you see here, or an IIS Managed account.  I prefer using domain accounts as we can control permissions via Active Directory. (NOTE: Just for security, we actually disable the ability for IIS Managed accounts to publish applications.  I’ll show you below.)
  5. Password – Duh?  If you choose to Save password, the password will be saved in the publish settings file for everyone to see.  I don’t recommend saving the password.  By not saving the password, a user will be required to enter their credentials every time in order to publish the site.
  6. Destination URL – Once the site is deployed, the URL will automatically be launched in IE taking you to view the application.
  7. Pressing “Validate Connection” should pass with flying colors and give you a green check mark.
After validating your connection settings, clicking “Next” will take you to additional options for publishing.
  1. Configuration – Allows you to choose which type of configuration settings for MSBuild and Web.config transformations to use.
  2. File Publish Options – Expanding this will give you a few additional options that we don’t care about here.
  3. Databases – If your Web.config has any connection strings, you’ll see a list of those connection string names here.  Often in remote (production, QA, dev, etc.) situations, you’re using an entirely different connection string.  You can place that alternative connection string here.  This will replace each of the connection strings you currently have in your web.config.
Now, you can click “Next” and you be directed to your last screen.  If you like, you can click on “Start Preview” to see the changes that must be replicated on the remote system.  Otherwise, you can just click “Publish” and you’re files should be deployed successfully.
Best of luck!