Client/server applications are back! Using the .NET framework, developers can build and deploy client/server applications much more easily. If you are thinking of building a moderately complex internal application using the browser as your user interface, think again and take a serious look at the .NET framework.

This is the second in a series of articles that try to answer the question: Why should my organization upgrade its development tools to the .NET framework? Microsoft has done an excellent job in building a next generation development environment. It is significantly easier to build web and client/server applications, to access and update information in databases, to move information to/from XML, and to build web services.

Unfortunately, Microsoft has done a poor job of marketing the .NET development environment. Many IT managers are confused by the alphabet soup of .NET tools—ADO.NET, ASP.NET, VB.NET, C#, CLR. They don’t know why they might want to upgrade to .NET. Building on our experience using .NET tools, we describe the business benefits that will accrue to companies that switch from a traditional Visual Basic 6 or C++ development environment to a .NET development environment. In this article, we will focus on building client/server applications using the .NET framework.

Client/server applications were common in the 1990s as PCs proliferated and IT managers replaced character-oriented mainframe applications with the easier to use graphical user interface of client/server applications. These applications, however, lost favor in the late 1990s with the growth of the worldwide web, the dot com bubble, and the spread of the browser as a user interface.

IT managers liked these intranet-based applications because they were much easier to deploy. As long as there was a browser on the users’ PC, they could run the application. There was no need to distribute an install to each user and no problems with dll hell. Most importantly, upgrades were easy. After you replace the application on the server, you can be sure that all your users were running the latest version.

In addition, connecting to a database or other data source was much easier with browser-based applications. You didn’t have to worry about establishing an ODBC connection from each user’s PC to the server database. All the work was done on the server. The user’s PC was the equivalent of a dumb terminal.

Both users and IT managers found significant problems, however, with the browser as a user interface. It was very hard to build complex applications in the browser. Simple user interface capabilities that users became accustomed to were difficult or impossible to implement in the browser. This includes: drag and drop, data validation for each input box, implementing actions on right click, printing reports, and using a wide variety of controls (e.g., spinners, splitters, sliders, and tree controls).

Once the ‘cool factor’ of building web applications wore off, IT managers became frustrated with intranet development. The tools for building user interfaces in HTML are poor. You can not just drag and drop controls onto a form. Developers often have to rely on Notepad to directly edit their HTML. In addition, the debugging and testing tools are not as sophisticated for web applications as they are for client/server applications. These factors led to harder to use applications with significantly higher development costs.

Now client/server applications are back. Microsoft has built a development environment and a set of tools that preserve and extend all the benefits of building client/server applications and overcome the shortcomings of these applications. Specifically, the .NET framework provides for:

• Simplified deployment. Installs are no longer needed for each application. The user must first install the .NET runtime (CLR) on their machine. Then to add a new application or to upgrade an existing application, you just need to use the XCOPY function to copy the folder that contains the application and its dlls onto the user machine. There is no need to register or un-register dlls. Different applications can use different versions of the same dll, eliminating “dll hell.”
• Easier to connect to data sources. The .NET framework provides several means of moving data between a server data source and the client application. The data can be moved as XML, allowing for easy access for anyone who is connected to the internet. Large quantities of data can be moved in binary format using ‘remoting’ when the client PC is on the company LAN. Finally, web services can be used to get data, providing a common method for data access for client/server, extranet, and internet applications.
• Better client/server development environment. Microsoft has made incremental changes to the development environment, adding new controls and exposing a great deal of operating system functionality through a new set of classes. This is especially appealing to Visual Basic developers. With Visual Basic.NET, they can now code many lower level functions that were previously only available to the C++ developer.

We have used these tools to quickly build and deploy several internal applications, including a timesheet system that works with Microsoft Excel as the user interface and a bug tracking system developed in Visual Basic.NET. We saw significant productivity increases over intranet applications and over Visual Basic 6 client/server applications using the .NET tools.

The bottom line is that the .NET framework has made it significantly easier to build client/server applications. We expect to see many organizations building all but the simplest applications using this client/server approach.