Introduction

In "Death of the Browser?" published in MSDN Magazine online, Billy Hollis writes tongue-in-cheek about the imminent demise of HTML, script, and ASP browser-based applications. Hollis talks candidly about beleaguered browsers being overtaxed in an effort to create rich client applications.

We know that Windows has been a capable platform for creating rich client experiences since early versions of Visual Basic. We also know that deploying a Windows application is not nearly as easy as point-and-click browsing to Web applications. Historically, if you needed rich clients , you wrote Windows applications, and if you needed almost zero deployment and broader distribution, you implemented Web applications. With .NET the chasm between these approaches is narrowing.

.NET supports copy-and-paste deployment for Windows applications. Copy-and-paste deployment works because the extra information needed to run .NET applications (called assemblies ) is carried around as metadata with the assembly. In conjunction with turbo-charged Run Time Type Information (Reflection) you can download assemblies over a network seamlessly in the background.

In this process a client starts with a very tiny application loader. The application loader refers to one or more assemblies using a URL. If the assembly does not exist on the client machine, it is downloaded. If the assembly exists on the client machine, the file date and time of the assembly on the client is compared to the file date and time of the assembly stored on the server. If the assembly on the server is newer , it is downloaded automatically. If the cached version is up-to-date, the cached version is used. This all occurs seamlessly without user intervention, prompts, verification dialog boxes, or anything; it just works. The result is automatic updating of applications with the ease of deployment of the Internet and a rich client experience.

There aren't enough of these thin, or smart, client applications for general expertise or wide acceptance, but some examples work beautifully. A fun example is the peer-to-peer application Terrarium, which uses an application updater to ensure that all peer clients are running the same version. The application updater works quite well in Terrarium, and my initial forays into thin client, auto-updating applications are encouraging.

NOTE

Terrarium is a peer-to-peer networked game. Programmers write plants and animals ”including herbivores and carnivores ”that compete for resources. If there are too many carnivores, they eat all the herbivores and die off; too many herbivores, they eat all the plants and die off. The goal is to create a competitive critter that outlasts all the others or to define a harmonious ecosystem that reaches a degree of homeostasis. The game offers several benefits: It is an engaging way to learn .NET programming, it demonstrates some of the cool features and capabilities of .NET, and it is a lot of fun to play.

In this chapter I tell you much of what is known to date about thin client, automatically updating Windows applications. Perhaps some of you will know a bit more, and I encourage you to contribute those experiences on your favorite forum. It is very likely that we will see a convergence of technologies so that programming for the Web and for Windows will be the same, resulting in rich clients as well as easy and broad deployment for all applications.

To begin we will take a look at a basic thin client application that deploys over the Web, and then we will tackle obstacles you are likely to encounter, including security management and deployment of COM components .



Visual Basic. NET Power Coding
Visual Basic(R) .NET Power Coding
ISBN: 0672324075
EAN: 2147483647
Year: 2005
Pages: 215
Authors: Paul Kimmel

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net