Month: October 2016

Web Site: .NET Multi Web Application Development

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.

Environment URL
Local https://localhost/apps/app1
Development https://dev/apps/app1
Test https://test/apps/app1
Production https://prod/apps/app1

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.

Modernizing a Classic ASP Web Application to .NET

Posted on Updated on

I’m currently working on a classic asp system started in the late 90’s. It was developed in ASP using Sybase. The system consists of a classic asp application, Windows PowerBuilder application, Windows PowerBuilder Batch applications, and Java Batch applications. The windows server is 2003 and Sybase is 12.5. The primary reason the database hasn’t been upgraded is because of the PowerBuilder applications. We’re in the process of rewriting the batch applications and the single Windows application by adding the features and capabilities to the web application.

It’s my understanding there have been two attempts to rewrite the system in Java, both attempts failed. Why did they fail? I’m not sure, but I believe it was because it was taking too long and the users were not happy with the UI. Based on my experience, doing a rewrite on a large system rarely succeeds because the tendency is to redo everything.

In the early 90’s there was an initiative at the company I was working to rewrite some DOS applications used by their sales engineers with a development team of three programmers. The initiative called for a new Windows 3.1 system to be developed in PowerBuilder. It was going to take 18 months to completely rewrite and deliver the system, seven years later was the first released. It was called a success, but I think it was management’s spin on something they couldn’t let fail.

Another time, I was asked to estimate a rewrite on a project that was written in Microsoft Access. My basic estimate was that it would take three developers about 3 to 4 years or 10 man years. Executive leadership went with a consulting firm because the effort was going to take too long and the consulting company could do it cheaper and faster. In the end, it took two full time developers (on-site) around six years to deliver the first release.

I’m not saying you can’t do a complete rewrite of a large legacy system, what I’m saying is that stopping everything and doing a complete rewrite is usually destined to fail. It’s no fault of anyone involved in the project, it’s a matter of expectations and what it takes to rewrite a large system. The time and resources required to redesign and rewrite a legacy system is significant and usually the task is grossly underestimated because management insists it can’t take that long, it’s only code.

Given that small rant, I believe any organization wanting to modernize their system needs a good plan in place and needs to look at how they can achieve modernizing a system without rewriting the system all at once. One thing I’ve noticed over the years is doing development in small chunks and delivering often (3 or 4 times a year) seems to work the best. Management likes it and users accept small changes easier than having everything change at once.

At my current place of employment, I believe we’re on a good track for rewriting the current asp system because we’re not trying to do everything at once. It’s going to take time and project management is trying to lay out the order of everything, but we’re doing small pieces for each release which allows us to make adjustments as technology and requirements change. We made the GUI look and work the same as the legacy system to make the rewrite as transparent as possible to the end user. So far, things are working out very well.

The basic architecture for the new system is to create restful web services for backend processing and use .NET MVC 5 with AngularJS for client side pages. It’s not complex and Microsoft has made it easy to create restful web services, which is helping the process. The biggest problems we have are related to Sybase and how Sybase works with the ORM (Dapper). As a whole Dapper works really well, except it does have issues with Sybase which (based on reading the internet) do not seem to be happening with SQL Server or Oracle.

How does the architecture look in the new system? In order to keep things short I’ll write about that in my next post, which could take a while.