A .Net Auto-Updating Project Template

This will be enough to satisfy me for now.  On to the fun stuff.

Auto-Deployment #1

For basic auto-deploy functionality, we first need to remove the pesky generic form that has been added to the deployment project and replace it with an empty class.  You may find use for the form later, but for now we’re doing basics only.  So we now have a class, AutoUpdaterMain, to start working with. 

Obviously we’re going to need a standard static void Main() method here or the compiler is going to get very angry at us.  So we’ll remove the class’s constructor (not needed) and replace it with the following:

[STAThread]
static void Main()
{
}

There.  We now have an app that does nothing.  Not a lot of fun.  Let’s make it show our UI.  Add a reference to your UI project in your deployment project.  Open your main class, make sure you have a using System.Windows.Forms reference, and add the following code to your main function (or something similar based on your project and form name):

AutoUpdaterTemplate.UI.Win.MainForm form = new AutoUpdaterTemplate.UI.Win.MainForm();

Application.Run(form);

Congratulations.  You now have a running app.  Try it out.  Not only that, but you’ve now written all the code you need for auto-updating scenario number 1.  Don’t believe me?  I’ll show you.  But first, one minor change.  Open the AssemblyInfo.cs file located in your UI project.  Change this line:

[assembly: AssemblyVersion("1.0.*")]

to this:

[assembly: AssemblyVersion("1.0.0.0")]

You’ll thank me later.

Now create a directory somewhere on your computer and copy the deployment exe and the UI dll from their respective debug folders into it.  Next, create a virtual directory, called AutoUpdater, from within IIS and aim it at this new directory.  Finally, type this into your web browser:
http://localhost/AutoUpdater/AutoUpdaterTemplate.Deployment.exe

Viola, your app runs.  But is it auto-updating?  Sure it is.  Here’s the test.  Open your Visual Studio command prompt and type gacutil /ldl.  This will list all of the files in your GAC’s temporary download cache.  See your UI dll?  See the version?  It should be 1.0.0.0  Ok, now change something about your UI’s form.  I’ll set my label to this:

Now change that AssemblyVersion to look like this:

[assembly: AssemblyVersion("1.0.0.1")]

recompile, copy the new dll into your IIS directory, and run it in your browser again.  You’ll see that whatever you changed showed up.  Not only that, but try the gacutil /ldl command again.  Now two versions of the UI dll are listed.  That’s right, the CLR determined that the version in your cache was old and downloaded the new one.  True .Net auto-deployment. 

Auto-Deployment #2 

So far, we would have to require that a user always follow a link to our app.  While this is fine for many applications, we’d like to make it as simple as running any other app on our computer.  No browser required.  So we’ll press on.

Ideally we’d like this to be as lightweight as possible, the best-case is having just a stub exe on the machine, and possibly it’s related app.config file.  However, this means the UI dll won’t be local on the user’s machine.  Goodbye reference.  We’ll remove that from our deployment project now.  However, now that we don’t have a reference to the dll, the code in our main method is broken.  We can’t create an instance of our main UI form in the same way.  What’s the answer?  Reflection.  As I shall show you now.

This article is not intended to teach you reflection.  It’s much too broad a topic and far outside my current scope.  As related to the current problem, it will be enough for you to know that reflection is going to allow us to create objects from within assemblies that we don’t have direct references to.

The first issue we need to tackle is that of how our exe knows where to look for our UI dll.  Normally the CLR would use the CodeBase property of our exe.  This is a reference to the place that the exe is located.  However, this is no good in our case.  We need a way to tell the CLR where to look.  Or, better yet, we’ll get the dll ourselves.  This will involve using the Assembly class, which will force us to add using System.Reflection to our list of using statements.  We’ll now start to rebuild our main method in this new manner.  We find we can load the assembly ourselves using the Assembly class’s wonderful LoadFrom method.  Here’s what we get:

[STAThread]
static void Main()
{
 try
 {
  string codeBase = "<A href="http://localhost/AutoUpdater/">http://localhost/AutoUpdater/</A>";
  Assembly uiAssembly = Assembly.LoadFrom(codeBase + 
                                     "AutoUpdaterTemplate.UI.Win.dll");
 }
 catch(Exception err)
 {
  MessageBox.Show(err.Message);
 }
}

I’ve chosen to abstract out the codeBase for reasons you’ll see in a minute.  Now that we have an instance of our UI dll we’ll need a little reflection to pull out our form.  This line should do the trick:

Type type = uiAssembly.GetType("AutoUpdaterTemplate.UI.Win.MainForm", true, false);

Finally, we’ll plug that form back into our application with this:

Application.Run((Form)Activator.CreateInstance(type));

And that’s it.  You now have a fully functioning stub exe.  The problem?  Remember the codeBase variable?  Yep, terrible idea to hard code that.  We’re going to look to the System.Configuration namespace to fix this.  Go ahead and add that using reference now.

Making It Flexible

System.Configuration is going to allow us to pull dynamic settings from an App.config file.  And so, we’re going to need one of those.  Let’s add one to our deployment project.  In our new App.config file we’re going to need an appSettings element as well as a codeBase element within that.  When all is said and done, our App.config file should look like this:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
 <appSettings>
  <add key="codeBase" value="http://localhost/AutoUpdater/" />
 </appSettings>
</configuration>

Now we can change that variable initialization line in our main method and we wind up with this:

[STAThread]
static void Main()
{
 try
 {
  string codeBase = 
                       ConfigurationSettings.AppSettings["codeBase"].ToString();
 
  Assembly uiAssembly = Assembly.LoadFrom(codeBase + 
                             "AutoUpdaterTemplate.UI.Win.dll");

  Type type = uiAssembly.GetType("AutoUpdaterTemplate.UI.Win.MainForm", 
                              true, false);

  Application.Run((Form)Activator.CreateInstance(type));
 }
 catch(Exception err)
 {
  MessageBox.Show(err.Message);
 }
}

This is a much better setup because we can now change the location of our UI dll without having to recompile, we merely change the config file.

You’ll now be happy to see that if you copy the deployment exe and it’s related config file to any location on your machine the app runs as expected.

BUT…is it auto-updating?  Well, do the test yourself.  Change your UI.  Update the AssemblyVersion.  Copy it to your IIS directory.  Now re-run the app from wherever you copied the exe on your machine.  Did it work?  Of course it did.  Would I steer you wrong?

Good To Know

FYI:  The AssemblyVersion update?  Yep, the CLR uses the version to determine whether or not to pull the new assembly.  You don’t need to update the version every time, but the new functionality won’t be downloaded unless you do, or unless you run the gacutil /cdl command.  This will clear your GAC’s temporary download cache, forcing the CLR to download whatever version is available.

Summing Up

That’s it.  We’ve now created an auto-updated app and managed to deploy it in two different scenarios.  It’s just that easy.  But is it?  Sadly no.  All of this has worked, and will work fine for very simplistic apps, but we must remember that auto-deployed apps in the previous cases are pulling resource from across the internet, and thus are subject to the mightly lock down Microsoft has placed on the InternetZone.  To accomplish more advanced features with our apps we’ll need to start looking into such topics as Code Access Security and Strong Naming.  Alas, those are topics for a more non-introductory article.  And if any of you out there are interest, just let me know, and I shall be happy to provide.

Good Luck.

Travis Merkel
v-trmerk@microsoft.com