Deploying Stand-Alone .NET Applications over the Internet, Part 2By Anthony Hart
In Read Part 1 we examined the foundations of auto-deployment in .NET. In this final part we'll examine the code needed to get auto-deployment going!
Show Me Some Code Already!
Now that we've gotten this far, let's take a look at an example to better illustrate the process. In this example, I have a "Hello World" application installed on the web server. It is composed of a single assembly named,
HelloWorld, which contains one class (a form) named,
frmMain. Keep in mind
that a WinForm in .NET is actually a class. If you'd like to take a look at the actual code of
at the end of this article there is a link to download it (but be warned: it probably won't be very
Assuming we already have the
HelloWorld application installed on the Web server, we can now take
a look at the intermediary application. In our example, we'll call it,
LoadFrom (again, there is
a link at the end of this article should you wish to download this code).
LoadFrom is a very
simple application. It contains only one form as shown below.
When the Load button is clicked, a call is made to the following code.
The process is fairly simple actually. First, an instance of the
HelloWorld assembly is created.
This is done by using the
Assembly.LoadFrom() method, which takes either one or two parameters.
The first parameter is the URL of the DLL or EXE residing on the web server (the
application in our case). The second parameter is optional and deals with security; but it is beyond the
scope of this article.
Once we have created an instance of the
HelloWorld assembly, we need to determine what type of
object we're dealing with. We do this by using the
Assembly.GetType() method and passing it the
name of the class we wish to instantiate. In our case, it would be,
Next, we create an instance of the class,
HelloWorld.frmMain by sending its type to the
Activator.CreateInstance() method. That done, we can now cast the newly instantiated class to a
Form object (just to play it safe) and then call the
Form.Show() method to show
the form. Note that you technically could have skipped a few steps to shorten the code as shown below, but
it's usually a better idea to go through the steps shown above in order to make your code more easily readable.
Under the Hood
When this application is run, it actually makes a copy of the assembly it calls and places it (and the requested class) in the "Application Download Cache". Then, if a different class is needed from the same assembly, it is copied over also. Note that assemblies and classes are downloaded into the Application Download Cache on an as-needed basis only. This is what is meant by the "trickling" mentioned in the quote earlier in this article.
Another really cool thing is that when an assembly is called, .NET looks for it first in the Application Download Cache. If it is found, a check is made with the assembly on the web server to see if the two versions jibe. If the assembly on the web server is a newer version, it is then copied into the Application Download Cache, allowing us to remain current.
So there it is! All the power of VB interfaces coupled with all the ease of Internet-based deployment. Does life really get much better than this?
Just to summarize, here are the general steps necessary to enable auto deployment:
- Both the web server and the client machine must have the .NET Framework installed on them.
- Install a .NET application on the web server (which has been compiled as either an EXE or DLL).
- Make sure the "Execute Permissions" setting for your virtual directory in IIS is NOT set to "Scripts and Executables".
- Create a lightweight intermediary application for distribution via email, FTP, etc., which uses the
Assembly.LoadFrom()method to instantiate the application which resides on the Web server.
That's about all there is to it. Give it a try and you will soon be the most popular guy in your IT department! Well, maybe not, but it will be rewarding and fun either way. Happy Programming!