Abstract
With Windows Server 2008 R2, the Server Core installation option introduces support for .NET applications including ASP.NET.In this article, we discuss how to install the optional roles and features that enable IIS and ASP.NET on Server Core. We also provide guidance on remote management and debugging of ASP.NET applications hosted via Server Core.
Related "5 Minute Concept" Webcasts
- http://channel9.msdn.com/posts/philpenn/How-to-Deploy-ASPNET-Applications-on-Server-Core
- http://channel9.msdn.com/posts/philpenn/How-To-Debug-ASPNET-Applications-on-Server-Core
Related MSDN Code Gallery Articles
- http://archive.msdn.microsoft.com/R2CoreApps
- http://archive.msdn.microsoft.com/r2core
- http://archive.msdn.microsoft.com/W2K8R2
Enable ASP.NET on Windows Server 2008 R2
Windows Server 2008 R2 Server Core includes subsets of the 2.0/3.0/3.5 .NET Framework. The Framework makes it possible to run an almost full-featured version of ASP.NET. However, there are 3 limitations that you should take into consideration when working with ASP.NET on Server Core:- No MMC Snap-in. To configure, host, and manage Server Core hosted ASP.NET websites, you must do so via a remote connection from an IIS Management Console (i.e. MMC snap-in) running on a client computer. You can also manage practically every aspect of IIS sites and applications via a local administrative command console using the command line utility APPCMD.
- No System.Web.Mail Namespace. The namespace System.Web.Mail is not supported because CDOSYS is not present on Server Core. The System.Web.Mail namespace was deprecated some time ago, so chances are that your code is no longer using them anyway. Use System.Net.Mail instead as it offers the same functionality.
- The Web Application Tool (WAT) is not available on Windows Server 2008 R2 Core.
Before installing the Web Server Role, IIS and dependencies, we must make sure that the .NET Framework is installed. To install the 2.0 and 3.0 .NET Framework, use the Deployment Image Servicing and Management (DISM) utility using the following parameters:
The optional server role that must be configured to enable ASP.NET on IIS 7 is called IIS-ASPNET. This role has various pre-requisites that must first be installed. The first one is the Web Server Role, which can be enabled via following command:
Once you have enabled the IIS-WebServerRole, three additional roles must be installed prior to the installation of the IIS-ASPNET role:
- IIS-ISAPIFilter
- IIS-ISAPIExtensions
- IIS-NetFxExtensibility
These roles are installed by issuing the following commands (in corresponding order):
Now, install the IIS-ASPNET optional feature using the following command:
Install the IIS Management Services
At this point, your Server Core install is capable of hosting ASP.Net applications. However, on Server Core, there is no IIS management console and no service running to leverage from a remote management console. This means that if you want to create web sites and web applications, you would have two options. Either use appcmd.exe, a command line utility found within the Windows system folder, or, enable the IIS Management Service and use an IIS Management Console from a remote client machine. Let's choose the remote management console option and install the Server Core IIS Management Service as follows.You must also install the WAS-WindowsActivationService and the WAS-ConfigurationAPI as follows:
Once installed, you must do some registry hacking in order to enable the service. The following command will set a registry key value that allows the remote management service to be started:
Although now enabled, the IIS Management Service is currently "stopped". Set the service to "started" using the following command:
Managing the Server Core Hosted IIS Server
Once your Server Core has been configured to allow the remote management, connect remotely by starting the IIS Management Console from a remote machine. Select the option to "Connect to a Server…" as follows:On the first subsequent screen, enter the name of the Server you wish to connect to:
The next screen will ask for your user credentials on the remote server:
The final screen will ask you for the name the connection:
Your server will now be listed on the Connections pane and the Management Console can now be used to configure web sites and ASP.NET applications as with any IIS Server installation.
Debugging ASP.Net Applications on Server Core
The first thing you must do is deploy the remote debugger service on your Server Core host machine. Setting up the remote debugger is illustrated a corresponding Code Gallery article entitledHow To Get Started with C++ and .NET Applications on Server Core, so if you are not familiar with this procedure, please make sure you read the related article before proceeding.Once the remote debugger service has been configured, install your ASP.NET application on the Server Core machine. There are several ways to do this, the easiest being to utilize the remote IIS Management Console. You must also copy the website files onto both the target Server Core host as well as the client machine where your Visual Studio debugging session will be hosted. It is extremely important that both versions are exactly the same. An easy way to ensure this is always the case is to create a project post-build step that will copy all of the website files to the target server core machine every time you compile your Visual Studio ASP.NET web application project.
Setting-up the Visual Studio Machine
On the machine with Visual Studio installed, create an empty Visual Studio solution to host your application. Then select the option to Add an Existing Web Site to the solution:When prompted to select the web site, don’t be tempted to select the Local IIS option, as we do not intend to debug the application with the local IIS service. Instead, select the File System option, and choose the folder that holds the ASP.NET application you wish to debug. In the screenshot below, the folder pointed by the red arrow is the folder that holds our sample ASP.NET application:
Once the project has been configured, it is just a matter of changing some of the default options from the project to make sure it connects to the remote Server Core install. The first task is to make sure that the Start Action is set to wait for an external application. This is done because, as you will see very soon, we will not be starting the application, but rather attaching to the remote process that is hosting the application:
Another option that must be configured is to select a custom server instead of the default Web Server. This is specified in the section below, and you must also specify the URL of the website you wish to debug on the remote server core install:
Once you are ready to debug your application, place the corresponding breakpoints you deem appropriate and load the web site by accessing the URL on the Visual Studio machine using Internet Explorer. Nothing should happen at this point, you are merely loading the web site so that the web server process on the host machine will run.
Switch over to Visual Studio and from the Debug menu, select the Attach to Process… option. From the dialog, select the type of code to debug or else you will run into problems trying to debug your code later on. From the Attach to: portion of the dialog, click the Select button and only select the debug managed code check-box as shown below:
Failure to carry-out this step will cause the debugger to try to debug T-SQL later-on when you do not intend on doing so.
You must now select the machine name from the Qualifier option. For instance, if your Server Core username is student1 and the name of your machine is Server2008R2, you would select the following option:
The next step involves attaching to the w3wp.exe process from the list of available processes (you must select the option to show processes from all users in order to see this process). If the process still does not display, reload your web page using Internet Explorer and then switch back to the dialog and use the Refresh button. Once the process becomes available, select it and click the Attach button.
It is now a matter of carrying out the necessary steps in your ASP.NET application to hit any of the breakpoints you set. Once this happens, the breakpoint will be highlighted and you will be remotely debugging your ASP.NET code from within Visual Studio: