This post describes how to create, setup and configure multiple web applications to appear as one application. It shows how to setup a development environment that uses localhost to works similar to dev, test and production environments. The only difference between the environments is the domain name in the URL. The following table is an example showing the difference in URL’s between different environments used in an organization.

Why is all this important? Have you ever had multiple versions of an application and needed to debug an older version? Or, have you ever developed an application using IIS Express (F5) only to have it look and work different once it’s deployed to dev?

A common reason for deployment problems developing locally on IIS Express (F5) is because it’s a different web server and physical paths don’t always match to the same relative path as the deployment server’s path, especially if you’re using virtual directories. This usually happens when there are common JavaScript and CSS files used in multiple web applications. I’m not an expert with IIS Express but it seems to use a location that is tied to where the project is located and is not the same as the IIS Web Site physical path.

Here the main question is, is there any way to setup and configure a development environment to provide consistent results when deployed to dev, test, and prod. My answer is yes, if you use IIS and localhost instead of IIS Express.

Advantages to using IIS instead of IIS Express

1. Modify JavaScript, CSS, cshmtl, and html files without rebuilding the web application,
2. Unnecessary to close browser each time for code, build, debug cycle during development of web application,
3. Access web applications in separate browser anytime, even when Visual Studio is closed,
4. Debug multiple web applications in one instance of Visual Studio

Step 1: Setting up physical directory structure
IIS configuration uses inheritance through the use of its web.config file. Knowing how to take advantage of it is important during development and deployment.

The default directory for IIS is C:\inetput\wwwroot, but it doesn’t have to be that directory. It can point anywhere. I like using the following structure because it allows me to create multiple websites on my development system.

In this example, the website physical path is D:\IISWebsites\localhost\wwwroot.

+- D:\IISWebsites
   +- localhost
      +- AdminScripts
      +- custerr
      +- logs
      +- temp
      +- wwwroot
          +- appName
          |  +- api
          |  +- apps
          |  +- web.config
          +- aspnet_client
          |  +- cdn
          |  |  +- angular
          |  |  +- bootstrap
          |  |  +- SmartAdmin
          |  +- css
          |  +- js
          +- Content

In IIS, the above folders show up under the Default Web Site as shown in the following image. While the folder structure looks the same, we’re putting the applications in a different physical location that separates them from the website.

+- E:\IISApps
   +- appName
      +- api
      |  +- WebApi01
      |     +- bin
      |     +- Areas
      |  +- WebApi02
      |     +- bin
      |     +- Areas
      |  +- WebApi03
      |     +- bin
      |     +- Areas
      |  +- WebApi04
      |     +- bin
      |     +- Areas
      +- apps
         +- WebApp01
            +- bin
            +- Areas
         +- WebApp02
            +- bin
            +- Areas
         +- WebApp03
            +- bin
            +- Areas

In IIS, the left pane looks similar to the following tree. The aspnet_client folder in each application is a virtual directory that points to the physical location defined by the web site, in this case D:\IISWebsites\localhost\wwwroot\aspnet_client. So far, this is they only way I’ve been able to share bundles between the web applications.

+- Default Web Site
   +- aspnet_client
   +- api
   |  +- WebApi01
   |  |	+- aspnet_client
   |  |	+- Views
   |  +- WebApi02
   |  |	+- aspnet_client
   |  |	+- Views
   |  +- WebApi03
   |  |	+- aspnet_client
   |  |	+- Views
   |  +- WebApi04
   |  	+- Views
   +- apps
      +- WebApp01
      |	 +- aspnet_client
      |	 +- Views
      +- WebApp02
      |  +- aspnet_client
      |  +- Views
      +- WebApp03
         +- aspnet_client
	 +- Views

So far, I’ve been able to use these concepts to work with TFS and SVN successfully. It’s helped me with my development of multiple web applications.