The web development space is awash with technology stacks and frameworks. There are now myriad techniques for building websites. Some work better than others. All have one thing in common, though. If you want to visit one, you have to request it from a web server. Sounds simple, right? Maybe if you’re a web development ninja and you’ve been doing this for decades.
But what if you’re not? What if you’re a desktop developer who’s just dabbled with web stuff? Maybe you are a web developer but you just haven’t got this far yet. Visual Studio has a web server built in, after all. You can build a website on your machine and run it. Website appears, happy days. Trouble is, you can’t host a production website using Visual Studio. Better use IIS then. How does it work though?
Let’s think about a desktop application for a moment. Once we’ve installed it, interactions tend to be seamless. We click stuff, screens change, new content appears. Stuff happens. It all takes place within the application though. If we’re not grabbing content from the internet, all the content lives inside the app. The toughest part is installing the app in the first place. If we’re dealing with a website, there’s nothing to install. As long as we’ve got a browser on our mobile or desktop, we’ve got a window into the website. We can interact with the content without installing anything (flash IS dead now, right?)
Our Journey Begins
Let’s start by looking at things from an end-user perspective. We’re looking for some information. Got a burning question that needs answering. Or maybe we’re a bit bored. Killing time. Endlessly browsing our Facebook or Twitter timeline. Looking for something, anything of interest. Then we spot it. What have we here? Let’s check it out. We click that link. We wait for a bit. Sometimes we wait for a while. Maybe we give up and go on to the next one! Eventually, stuff happens. The content appears, as if by magic. For most of us, that bit in the middle is a black box. Let’s dive into that box and see things from the internet’s perspective.
The Bit From Your Browser to the Web Server
So, what brought you here, to this page? You may well have typed in or followed a link to levelnis.co.uk. Maybe you even had it as a bookmark (thanks for that!). Either way, your browser found its way to this site via the domain name levelnis.co.uk. How does it know where to go though? Every machine or device connected to the internet gets assigned an IP address. Think of it like a phone number for the website. Domain Name Servers (DNS) act as a phone book. They look up a domain name and find the IP address it points to. There’s a whole bunch of them on the internet, routing traffic around. Your Internet Service Provider views the DNS linked to the domain. Armed with the underlying IP address, it routes you to the right website.
So What Happens When We Get to the Web Server?
The website itself needs to live on a web server that can handle the request. The server needs to be available. It needs to understand your request. For the purposes of this article, we’re talking about an ASP.NET MVC website. It’s more than likely hosted on a Windows server. With the advent of ASP.NET Core, we can host on Linux, but I’m not focusing on that. So, it’s a Windows server. That means it runs Internet Information Services (IIS). That’s a key piece of the jigsaw. Without IIS, your website is just a collection of files.
IIS has evolved as MVC has evolved, and the 2 play very nicely these days. In fact, they have since IIS 7, which shipped with Windows Vista and Windows Server 2008. Let’s home in on a more modern version, IIS 10, which shipped with Windows 10 and Windows Server 2016. In a moment, we’ll look at how to set a website up in IIS 10. Before we do that, a brief word on what happens after. Once IIS processes your request, it passes it to the MVC routing module. You’re then into the MVC Request Lifecycle. I won’t cover that in this article, but there’s a useful write-up here: A Detailed Walkthrough of ASP.NET MVC Request Life Cycle.
Let’s Configure a Website to Use IIS
Righty, a practical example. That always helps when trying to learn something. Chances are, if you don’t use IIS already, it won’t be on your PC. You need to enable it from Programs and Features. To find out, click Start > Run and type inetmgr. It will either load IIS or complain at you. If it complains, follow these steps to install it:
- Head to Programs and Features within Control Panel:
- From the left hand menu, click Turn Windows features on or off
- Scroll down to Internet Information Services and select it
- Expand World Wide Web Services > Application Development Features and select ASP.NET 4.6
- Click OK and Windows will install IIS. You can now type
inetmgr into the Run box again and load IIS.
Once it’s installed, you should see something that looks a bit like this:
On the left, we’ve got application pools and sites. If you expand sites, you should see Default Web Site. Let’s go ahead and configure a new website. The first thing we need is an MVC project, so I hope you’ve got one ready! I’m going to configure our old friend, DataTables. We’re going to create an application pool for it before we start. Every site in IIS should have its own application pool. This ensures we can restart it without affecting other sites on the server. We’ll see why in a moment. Right-click on Application Pools and add a new Application Pool. Here’s mine:
Make sure it’s running against the same version of the CLR as your website. Keep managed pipeline mode set to Integrated. If you switch it to Classic, you’ll have a load of extra work to get your MVC website to play nicely.
It runs under ApplicationPoolIdentity to start with. That’s fine for most things. If you have to run it as a specific user, change that from Advanced Settings.
Right, step 1 done. Now let’s create the website. Right-click on Sites and add a new website. Give it a name and select the application pool we created in the previous step. Set the physical path to the root folder of the website. Give it a random port. I’ve selected 901, but you can select any number between 0 and 65536. Steer clear of any of the well-known port numbers though! If you leave it on port 80, it will clash with the default web site.
View the original article.
Leave the Host name blank and click OK to start the website. The port number forms part of the URL, so I’m going to open up http://localhost:901/ in my browser and check out my website:
Final Thoughts: Debugging and Multiple Application Pools
Remember how I mentioned that every site should have its own application pool? Well, this is important if you want to restart the website for whatever reason. The application pool relates to a worker process running on the server. Have a quick look in Task Manager and you’ll see what I mean. Hit CTRL-Shift-Esc and click the Details tab. Whenever a website starts within an application pool, this starts a w3wp.exe process on the server. You can see the ones running on my machine here:
They’re all running under Application Pool Identity, which makes them easy to tell apart. If I need to restart the application, I can do this through IIS. I can also do this through Task Manager by killing the w3wp process. It’s important to know which one to kill though! Otherwise, I’ll be stopping the wrong website. That wouldn’t be ideal.
Useful Tools for your IIS Toolkit: AppCmd.exe
What happens if I’m running them all under the same username though? Imagine all those w3wp entries showing levelnis\DevTest as the username, for example. This happened to me on a recent project. The websites all ran under a specific Active Directory account. This allowed the DevOps team to control server and database access. It meant that I couldn’t tell which process was which when I was debugging. There’s a tool for that though, which we’ll look at now. It’s called AppCmd.exe and can show you which website goes with which process. Here’s how you do it:
- Open an administrator command prompt. On Windows 10, right-click the start icon and it’s in the menu. If it’s not there, search for cmd. Once Windows finds a match, right-click the command prompt and run as administrator.
- Navigate to C:\Windows\system32\inetsrv.
- Type
appcmd list wp - this gives a list of PID to app pool name, which allows us to locate the w3wp process by PID. In my case, 11300 is the one I want. I can now use that if I want to attach to it in the VS debugger.
View the original article.
