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.
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.
Great article on why good employees leave their job.
Just finished a class on AngularJS. The title of the class was Developing Web Applications Using AngularJS. It was a four day class and the instructor was Brad Gillespie who was a very good instructor. Overall, I have to admit it was a pretty good class that provides an overview on the basics of using angularJS on the client side for web applications, which fit in perfectly for where we’re at with regards to our system.
We are currently in the process of remodeling our legacy Classic ASP web application into several .NET web applications. We’re using .NET WebApi 2.x for restful services and .NET/MVC 5 and angularJS for client side applications.
For the restful web services we’re breaking those into several applications by function, which at the moment is by main menu classification. We’ve created three client side applications, one for admin, education institutions, and educators.
For the end user, there is little difference in the appearance of the system. The menus, page headers and footers are the same as the original application. As we replace existing pages we’ll be able to remove them from the legacy application.
I estimate the remodeling or rewrite will take about seven years to complete when we consider enhancements, bug fixes and changes we’ll be required to make because of changes in state and federal laws.
This is a picture of the certificate that says I completed the class.
Great article published in People & Culture Magazine, found this article on Flipboard August 11, 2016. Forget Technical Debt — Here’s How To Build Technical Wealth
How does one approach legacy code? Andrea Goulet and business partner Scott Ford love legacy code. Andrea and her team believe people are more than just makers, they are menders too!
Here’s 3 paragraphs from the article I think describe most of the development efforts I’ve been involved in over the years.
Sure, it might not make sense to test compulsively when you’re pushing toward a prototype. But once you have a product and users, you need to start investing in maintenance and incremental improvements. “Too many people say, ‘Don’t worry about the maintenance, the cool things are the features!’” says Goulet. “If you do this, you’re guaranteed to hit a point where you cannot scale. You cannot compete.”
As it turns out, the second law of thermodynamics applies to code too: You’ll always be hurtling toward entropy. You need to constantly battle the chaos of technical debt. And legacy code is simply one type of debt you’ll accrue over time.
“Again the house metaphor applies. You have to keep putting away dishes, vacuuming, taking out the trash,” she says. “if you don’t, it’s going to get harder, until eventually you have to call in the HazMat team.”
I see this a lot. Start on a new system and the initial focus is to get it working and usable and no one is really concerned with the structure of the system or how the code looks as long as it works. Once the initial system is working, work on fixing bugs and implementing enhancements. The end result is, we never go back to refactor the code base, especially the parts that could be promoted into base classes and generalized to help move towards following the basic principals defined in the SOLID acronym.
It’s an easy trap to fall into because management is focused on moving forward with new development and as long as the system works, why go back and take time to improve the code base that no one sees but the developers.
Whenever we started a new application, I had one director who would always say, “every project has a start and a finish”. Once it’s finished the application goes into maintenance mode not to be touched again unless absolutely necessary. Once an application was delivered to production we spent the next several months fixing bugs, after that the system wasn’t looked at again.
One of the short comings of that thought process was the lack of understaning how everything worked or fit together. There wasn’t time to create technical wealth. The director couldn’t understand how working on one application could benefit all applications in the system. They were missing the point about software development and not looking at the big picture, which makes is worth quoting the following statement from the article.
I know it’s hard to go back and refactor code once because it seems like you’re spending too much time on one area of code. If the system is around long enough there are parts that will need to be revisited several times to keep it going and making it better so you won’t need to rewrite it from scratch in five or six years.
It’s like a house, when the foundation and the frame are solid and flexible, it has a better chance to survive anything bad happening around it.
Great post by Bill Jordan on May 27, 2016. He made a lot of good points about software developers and the state of software development.