Aside Posted on Updated on
Multi-web Application Development – Part I
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?
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
- Unnecessary to close browser each time for code, build, debug cycle during development of web application,
- Access web applications in separate browser anytime, even when Visual Studio is closed,
- 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.