Internet Deployment

Team Fly

Page 246

This type of deployment is new to .NET and you'll find it extremely convenient if you're working for a company that uses an intranet. Internet deployment is also known as no-touch deployment, because you don't have to install the application on the target machines. Users can connect to a web server and download the application to their workstations, where it will be executed. It's also known as zero-install and zero-administration deployment, and we'll explain why immediately.

The problem with installers is that every time we make a change to the application, we must create a new installation project and redistribute the application to all clients. Deploying an application to hundreds of user desktops is a nightmare for system administrators, which explains the popularity of Web applications. Web applications run from a web server, and no components need be installed on the client computers. However, a browser-based application can't offer the rich user experience of Windows forms applications. A WebForm can't provide immediate feedback to user actions as Windows forms can, and WebForms make numerous trips to the server. With no-touch deployment, we can simply copy the files generated by the compiler in the application's Bin folder to a virtual folder on the company web server and be sure that all clients will see the latest version of the application. In short, no-touch deployment combines the best of Windows forms– and WebForms–based applications. The executables are downloaded to the client where they're executed, while no components are installed at the client.

Internet-based deployment eliminates the problem of distributing upgrades. You can simply replace the original executables on the web server with the newer ones, and the next time a user connects to the application, they will see the new version. If you're developing an application in a corporate environment, this type of deployment is your best option, because you can upgrade your application on all desktops with zero downtime. You'll never have to ask users to stop their applications and install a newer version. The worst-case scenario is that you may have to ask users to exit the application and restart it.

To run an application from a web server, users must start their browser and enter the URL of the application's main executable file on the server. Alternatively, you can create a simple web page with a hyperlink to your application and ask users to connect to this page's URL. If your company runs an intranet and users connect to a starting page every morning, you can place the hyperlink to this page.

Note that users need not start their browser to connect to an application deployed through a web server. They can create shortcuts to the URL of the application on the desktop and start the application by double-clicking this shortcut. When the shortcut is double-clicked, the browser's window comes up for a moment and then the application's form will appear.

With this type of deployment, the application's files are copied to the download cache of the client, from where they'll be executed. Every time the user starts the application, the CLR compares the hashcode of the application in the local cache to the hashcode of the application on the web server. If they're the same, the application is started from the cache. If not, the CLR downloads the newer version from the web server to the cache and then executes it. As you will see, it's possible to download components from within the application, a technique that allows you to download components on a separate thread while the application is running. Practically speaking, you aren't going to use this type of deployment unless you know that all clients have a high-speed connection to the server. This means that new components won't take long to download to the client, so you expect users to wait for a few moments to download the newer version of an application (or component) from time to time.

Team Fly