Introduction
I have been working with ASP.NET Core for a while now and always missed the direct IIS support in Visual Studio. Having to remember to spin up the project to start IIS Express is a bit of a nuisance. When developing software, we want the actual debugging and run processes to be as automated as possible, and with IIS express, they simply aren’t.
It is much quicker to simply launch a browser and debug JavaScript instantly, without an extra step in making sure that the IIS Express site is actually running. And, no need to start and stop your website, making development that much quicker.
Essentially, the goal is to have your web server running 24/7, without having to think twice about it. So, the first step is to actually enable IIS on your development machine:
Enable IIS
- Navigate to Control Panel > Programs > Programs and Features > Turn Windows features on or off (left side of the screen).
- Select the Internet Information Services check box:
The next step is to configure IIS and ensure you have an SSL certificate setup to run your site securely in the browser. If you’ve already installed IIS previously, simply add an HTTPS binding to allow https on your default web site.
Configure IIS
The Host name for our new website is set to “localhost
” (the launch profile will also use “localhost
” within Visual Studio). The port is set to “443
” (HTTPS). The IIS Express Development Certificate is assigned to the website, but any valid certificate works:
The first 2 steps are straightforward, and are the same no matter whether you are using .NET Framework or .NET Core in your applications. I have managed to debug with IIS using Visual Studio 2017. So, I highly recommend that you install Visual Studio 2017, if you haven’t already.
Next, we have to enable development time IIS support in Visual Studio:
Enable Development-Time IIS support in Visual Studio 2017
- Launch the Visual Studio installer.
- Select the Development time IIS support component. The component is listed as optional in the Summary panel for the ASP.NET and web development workload. The component installs the ASP.NET Core Module, which is a native IIS module required to run ASP.NET Core apps with IIS:
Now, we can finally create a new ASP.NET Core application in VS2017. Well, not quite yet! I had followed several articles, both from Microsoft and other developers, but they were all missing the key component: ASP.NET Core 2.2. Don’t use 2.1 or any other version. I couldn’t actually get my application debugging within IIS, without 2.2. But, that’s the main reason I write an article like this. Instead of going through other articles, that don’t cut it, I learn what I can from them, and create a better article that actually gets developers where they need to be, without leaving important information out.
Now that you’ve got .NET core SDK 2.2 installed, we can finally create a new project:
Create New ASP.NET Core 2.2 project.
Make sure to select the check box to Configure for HTTPS when creating a new project:
Next, we need to configure the debug tab within our new project. This involves setting up a launch profile to launch IIS correctly:
IIS Launch Profile
Create a new launch profile to add development-time IIS support:
- For Profile, select the New button. Name the profile “IIS” in the popup window. Select OK to create the profile.
- For the Launch setting, select IIS from the list.
- Select the check box for Launch browser and provide the endpoint URL. Use the HTTPS protocol. This example uses https://localhost/TestIISWithCore.
- In the Environment variables section, select the Add button. Provide an environment variable with a name of
ASPNETCORE_ENVIRONMENT
and a value of Development
. - In the Web Server Settings area, set the App URL. Set it to the same as the URL you entered in Step 3.
- Save the profile:
You should now be able to debug your application with IIS. Make sure to set your build configuration to Debug, and the profile to IIS. Then click the run button to start your application:
There you have it! You can now officially debug your ASP.NET Core apps within IIS. Of course, this is still a matter of personal preference, I always preferred debugging my apps within IIS instead of IIS Express.