Feb 08, 2014 · 5 minute read
One of the simplest and quickest ways to publish your website to a staging environment is, at least in my opinion, using Microsoft Web Deploy. This post is about how you approach this, a future article will discuss why you probably shouldn’t do this. Key points;
- The remote server should be running Internet Information Services (IIS) 7.0 or later.
- You can use the Microsoft Web Platform Installer to install all the extra bits you need to make this work.
- You need to set appropriate permissions to allow remote publishing.
On my local machine, for testing purposes, I have a Windows Server 2012 R2 virtual machine which is bare bones configured. The first thing you need to do is install IIS. You can do this using the Server Manager; Open the Server Manager > click Add roles and features > select Role-based or feature-based installation > select the target server > and finally, select Web Server (IIS) and Windows Deployment Services. Feel free to drill into each item and ensure you have the following selected (as well as whatever the defaults are);
- Basic Authentication (very important)
- ASP .NET 3.5 / 4.5
- .NET Extensibility 3.5 / 4.5
- IIS Management Console and Management Service (very important)
Once installed, you should be able to open IIS Manager by opening the Start menu, type inetmgr and press enter. When IIS Manager opens (referred to herein as IIS), you should be prompted to download Microsoft Web Platform installer. Ensure you do this. Use the Web Platform installer to ensure you have all the following installed;
- IIS 7 Recommended Configuration
- IIS Management Service (should already be installed)
- IIS Basic Authentication (should already be installed)
- Web Deployment Tool (The current version is 3.5 at the time of writing, I also like to install Web Deploy for Hosting Servers as well)
- Current version of the Microsoft .NET Framework
- ASP .NET MVC 3 (as we will be publishing an ASP .NET MVC website)
I like to do a restart at this point, just to ensure that everything is tidied up (although I don’t think its 100% necessary, just ensure you restart IIS at the very least).
The next step is to “switch on” the web management service. This will allow remote users to connect up and deploy the website. For the sake of simplicity, we will use basic authentication. There are other means of authenticating users, but that is out of the scope of this tutorial.
In IIS, select the server level node and then select the Authentication module (under the IIS grouping). Simply right click on Basic Authentication, and the click Enable. Next we need to configure the web management service to accept incoming connections. Again, select the server level node, and select Management Service. If the management service is already running, you need to stop it before continuing. To do this, go to the Start Menu and type services.msc. This will open the Services manager. Search for Web Management Service, right click, and click Stop. I ran through this process twice from scratch and the first time the service wasn’t running and the second time it was. I not sure what triggers it to run. Tick Enable Remote Connections and feel free to accept the default settings for now. You could always revisit this later. Click Start on the right hand side to start the service.
I’m sure you’ve done this many times before, so I will not regurgitate the details here. Add a new website, give it a host name if you like, and specify the physical path (remember this). Please ensure that you set the application pool to .NET CL**R Version 4.0.30319** to avoid errors running the website further down the line.
IIS requires read permissions to access the files that make up your website. The simplest way is to head over to the physical folder for your website (that path you’re remembering from earlier), right click the folder, click Properties > Security > Edit > Add. Type IIS_IUSRS then click Check Names. Click OK, then OK to close the properties windows.
Finally, you can create a web deploy publish profile (simply an XML file with a few basic settings) which you can import into Visual Studio to save you the hassle of having to type anything.
Head back over to IIS, right click on your website, click Deploy > Configure Web Deploy Publishing. You can (and definitely should) create a restricted user account and grant permission to publish to that account (either an IIS account of a Windows authentication based account). Once you have selected a user, click Setup. A message should appear in the Results text area;
Publish enabled for 'WIN-DLICU73MRD0Jon' Granted 'WIN-DLICU73MRD0Jon' full control on 'C:inetpubwwwroottestwebsite' Successfully created settings file 'C:UsersJonDesktopWIN-DLICU73MRD0_Jon_TestWebsite.PublishSettings'
Success! This is your publish profile that you can import into Visual Studio.
To import your publish profile, open your web solution and from the Build menu select Publish [your website].
On the Profile tab, click Import… and browse to the publish profile you just created. Once imported, switch to the Connection tab and type the password for the account you selected earlier on the Configure Web Deploy Publishing dialog you saw earlier. If you’re feeling lucky, hit the Validate Connection button. All should validate properly. If not, please refer to this little hidden gem from the IIS team to help troubleshoot any error messages you might be receiving. Browse to your website using the host name you specified earlier (don’t forget to update your hosts file if you are “just testing”) and congratulations, after the initial feels like a lifetime compilation period, all should be good. Next time you’re ready to publish, simply open the Publish dialog in Visual Studio, go straight to the Preview tab and hit Publish. No more manual deployment for you my friend!
The Microsoft Web Deployment tool is a quick and convenient way to publish your website to a staging area for further testing. You use the web deployment tool to generate a publish profile which can be imported into Visual Studio (saving you the hassle of having to type all that connection info) and then call that service and pass it a package which will automatically deploy your site to the appropriate folders.
About the author
I am Jon Preece, an experienced website and software developer from the United Kingdom, based in Manchester.
Throughout my 10+ year professional career I have worked in many sectors, including; e-commerce, financial services, marketing, healthcare, travel and accountancy. Get in touch via Twitter.