Distributed Applications Developer IT Search US-TX-Dallas Post A Job | Post A Resume

Deploying Stand-Alone .NET Applications over the Internet
By Anthony Hart

---

Summary (a note from Scott Mitchell...)
This article discusses how to deploy stand-alone .NET applications over the Internet. That is, desktop applications you create with .NET-compatible languages, such as VB.NET or C#. This particular article doesn't deal with ASP.NET specifically, a follow-up article will. I debated whether over posting this to 4Guys since it doesn't deal specifically with ASP.NET, but .NET desktop applications. However, I think it is a very neat article highlighting some of the neat, neat things .NET is capable of. And, since these desktop applications are deployed via the Internet, there are many Web developers who may find this information useful. For example, if you are designing a rich Web site that requires the client have a particular application (such as Streamload.com, which allows users to upload files to their servers and utilizes a custom-made tool to facilitate mass uploads), this technique may be more beneficial than requiring the user to download an applet or executable file.

Introduction
One of the exciting things about the .NET revolution is Microsoft's apparent attempts to combine the power of Windows programming with the flexibility and reach of Internet programming. I see this as a very positive effort that has the potential of changing (for the better) many of the programming paradigms that have developed over the past several years. This article will deal with some of my findings regarding a technique in .NET that Microsoft has dubbed, "auto deployment".

Deploying Web Applications vs. Deploying Software Applications
I started developing software using C/C++. A company I worked for later used Delphi for everything (and a Paradox databases – aptly named, in my opinion). None of the projects I had worked on had anything at all to do with the Internet. All I knew of Internet "programming" was a little HTML. Deploying these applications was anything but easy, seeing as we had to get our product to our customers and clients. The easiest way for them to obtain our latest version was to download the binaries, some install file perhaps, but they still needed to go through the process of installing the program, and repeat that process for every machine they wished to use our application on. Furthermore, when we'd publish updates of our software, our users would have to go through the same song and dance all over again.

You can imagine my elation when I was introduced to ASP! I could actually program for the Internet! Wow! One of ASP's greatest strengths, which is really a strength of the medium more so than a strength of ASP specifically, is that upgrading and modifying your Web application is really easy and happens in real-time. Compare that to a program like Microsoft Office, where you have to go to a store and buy a cardboard box with little plastic discs inside to obtain the new features and functionality. Simply put, you don't have to go tell a bunch of disgruntled users that they need to download and install the latest updates to the application. All you need to do is update your application on one server and away you go. No installation files, no registry games, no caked-on dirt, no streaking, no mess – and don't forget the fresh lemony scent.

Another strength of ASP applications (and, again, Internet applications in general), is that they are accessible from virtually anywhere and from various devices. The user is not limited to sitting at his desk, using one particular computer to access the application.

Clearly Web applications have advantages that desktop applications do not – and vice versa. While ASP applications are easier to deploy and update, desktop applications allow for more control and provide a better experience altogether since they can be much larger in size and scope. As developers we are often faced with the dilemma of either giving up the power of a compiled application for the flexibility and ease of deployment of an ASP application, or we sacrifice wonderful interconnectivity in order to retain the power and dependability of a desktop application. We have to rob Peter to pay Paul, so to speak.

.NET's Auto Deployment to the Rescue
At least, that was true until the advent of the .NET framework. .NET has come to the rescue by providing what they have called, "auto deployment". Now we can build standard desktop applications utilizing WinForms that can be deployed at runtime over the Internet! (WinForms is a framework for building .NET client applications. To learn more about WinForms, check out the WinForms QuickStart Tutorial.) By being able to deploy desktop applications over the Internet, we are allowed to follow a deployment model similar to that of an ASP Internet application. We can have our cake and eat it too.

Now, there's not a whole lot of documentation on this topic so far (at least, I had a heck of a time finding any), so consider yourself lucky if you are reading this article. As a matter of fact, in the first part of September, I went to Microsoft's .NET Developers' Tour and they only mentioned it in passing and then moved on to another topic. In the manual they gave us, the only semi-helpful text I could find about auto deployment was as follows:

With a Windows Forms application, it is unnecessary to deploy an application to the end user's desktop. Instead, a user can invoke the application simply by typing a URL into a browser. The application will download to the client machine, run in a secure execution environment and it can remove itself upon completion.

Auto Deployment needs no installation:

• Store the assembly on the Web server
• In the applications, use Assembly.LoadFrom
• The application is downloaded, form by form as needed via the HTTP Web server
• It is stored in the GAC and the Internet download cache
• It is only downloaded as needed or when updated
• Dependent components are automatically downloaded to the client so the application "trickles" onto the client

If you use an installer, the installer can download the .NET runtime for installation.

No examples, no further explanation, no references to Web sites or literature where I could learn more, so I'm here today to explain to you how this whole thing works.

First, you develop a .NET WinForms application just as you normally would. Compile it as an EXE or DLL. In the only article I found on the subject, I read where it is recommended that we compile it as a DLL, but the author doesn't explain why. In my own tests, I have found that an EXE and a DLL work equally well. That said, it actually seems to make more sense to me to compile it as an EXE – that way, if we ever decide to use it as a normal desktop application, we don't have to re-compile at all. Until I hear a reasonable explanation as to why we should use DLLs instead of EXEs, I will continue to use (and recommend) EXEs for auto deployment.

Next, copy the application's files to a Web server (remember that the web server must have the .NET Framework installed on it). One of the things I really love about .NET is that installation is almost a non-issue – just copy the application to where you want it and then continue reading your Spiderman comic book.

One thing to note is that in my experimentation with auto deployment, I have found that I have needed to change a setting in IIS on the Web server. In order to change this setting, open "Internet Services Manager", right-click on the virtual directory in which your application resides, and select "Properties". Click on the "Virtual Directory" page of the Properties dialog and you will find the "Execute Permissions" setting. Make sure that it is not set to "Scripts and Executables" (see the image to the right for a screenshot). Any other setting will do.

Once you have the application installed on a Web server, you can write a very small intermediary application whose sole reason for being is to call the application residing on the Web server. This intermediary application would be simplistic, small, and very easy to distribute. There's no reason that it couldn't be emailed out to all your enterprise-wide users or downloaded from your company's FTP site. Keep in mind that the user receiving the intermediary application needs to have the .NET Framework installed on his machine.

Essentially, this small intermediary application will reside on the user's machine and execute the remote application. Imagine that we wrote some sort of financial calculator that, for one reason or another, needed to be updated frequently. Rather than requiring users to continuously have to download a new version every time the program changed, we could send our users this intermediary program that, when run, would make a call to our Web server and invoke our financial calculator program. The most recent version of the program would be scuttled over to the user's machine and run from there.

Now that we've examined the foundation of auto-deployment in .NET, it's time to look at some code, which we'll do in Part 2.

Read Part 2!

Windows Internet Technology | ASP.NET [1.x] [2.0] | ASPMessageboard.com | ASPFAQs.com | Advertise | Feedback | Author an Article