Introduction

In today's world, applications are quickly moving towards a simple, all-encompassing distribution model. Web applications are gaining popularity because of their scalability and ease of deployment, and desktop applications are becoming less common. This holds both positive and negative consequences - mainly with functionality and user experience.

Most applications need to ensure the best user experience possible for any given situation. In many cases, a web site meets the needs of both the developer and the consumer. However, some applications are better suited as a client-side, distributed application.

For these applications, the need arises for an easy and reliable method of deployment that allows the application the flexibility for any scenario. It should gracefully handle updates to the application, and be easily managed remotely. For this reason, DDay.Update came into existence - to provide an easy interface for adding automatic update functionality to your application, avoiding most of the headache involved in the update process, while allowing the most flexibility possible.

Background

The technology that will be presented uses Microsoft's ClickOnce publishing mechanism that is built into Visual Studio 2005. It does not use ClickOnce itself. This is for many reasons:

It's difficult to use your own deployment methods (use Windows Installer, for example) and still use ClickOnce for automatic updates.

You cannot easily update individual files with ClickOnce, it's an all-or-nothing update, by default. This becomes problematic when your application is anything but very small in size, or you have very few users.

To use a different GUI with ClickOnce requires a complete, built-by-hand interface. DDay.Update's GUI is pluggable. There is currently a pre-built interface for Windows Forms 2.0, and one will soon be available for .NET 3.0 (WPF).

DDay.Update does not interfere with your application's security permissions.

Open source applications lend to a better understanding of the underlying technology. Since DDay.Update and all its controls are open source, you are free to study and extend the code.

That said, if you haven't already, I encourage you to give ClickOnce a try. You may find that it suits your needs. When you find some of its features lacking, then give DDay.Update a try.

Note: DDay.Update is not a wrapper for ClickOnce. It simply consumes ClickOnce manifest files.

OK, what now?

In this article, I will present a bare-bones application, and give it automatic update functionality.

Preparation

First, download the most recent binary version of DDay.Update from SourceForge.net. It is also included in this article for convenience.

Once downloaded, you're ready to begin.

We will now go through the following steps:

Step 1 - Create an application to be automatically updated

Step 2 - Publish the application

Step 3 - Create a Bootstrap application

Step 4 - Test it out

Step 1 - Create an application to be automatically updated

Create a new Console project in Visual Studio. Click File->New->Project, and select "Console Application" from the list. I named mine "AutoUpdatingApplication". You can choose whatever name you'd like (though it may be easier to follow examples if you use the same name).

Add a basic line of code to this application, such as:

Console.WriteLine("This is my application.");

Step 2 - Publish the application

We will use Visual Studio's ClickOnce mechanism to publish this simple application. This process is very simple. If you already know how to publish a ClickOnce application, skip to Step 3.

Then, click on the "Publish" tab on the left, and click the "Publish Wizard" button:

Then, follow the steps of the wizard. Here's what I did:

Click "Finish", and your application should now be published to the location you indicated in the first step of the wizard. In my case, it's "C:\Deployment\DDay.Update.Test".

That's it, your application should now be published through ClickOnce!

Step 3 - Create a Bootstrap application

DDay.Update uses a bootstrap application to "mimic" the look and feel of your "real" application. In order to create this Bootstrap application, you need to use the Configuration Tool included in the binary distribution of DDay.Update.

First, open the Configuration Tool that you downloaded in the Preparation step of this example. Then, select File-> OpenDeployment Manifest.

You will then see the following screen:

Enter the location where you published your application. This will include the name of your project, with a .application extension. In my case, it's:

C:\Deployment\DDay.Update.Test\AutoUpdatingApplication.application

Then, click Open. You will then see the main configuration screen, with some information automatically determined. The Update URI should already be provided - if it isn't, it should match the location where you published your application. In my case, it's C:\Deployment\DDay.Update.Test. When an Update URI is provided, you can click the "Verify URI" button to ensure that the URI is valid:

Then, choose an update notifier. This is the "pluggable" GUI that DDay.Update uses to display update information to the user.

Afterwards, choose a destination folder for the Bootstrap application to be created. I added a new folder on my desktop:

When you've completed these steps, you're ready to build the Bootstrap application. Click the "Create Bootstrap" button, and you should see a message as follows:

Then, the destination folder will automatically open, and you'll see your brand-new Bootstrap! If you run the executable in that folder, you'll see your application download the most-recent version and run it, and your folder will look like this:

Notice the folder named "1.0.0.0". That's where your "real" application is stored.

Step 4 - Test it out

To see the update in action, open Visual Studio again, and publish a new version of your application. Then, go back to the "destination folder" where you created your Bootstrap, and run the application. You should see a message as follows:

Select "Upgrade Now", and the new version will download and run. You'll also notice that the directory structure of your application looks like this:

Notice the new "1.0.0.1" folder. The new version of the application has been placed here.

Note: If you chose "Upgrade Later", version 1.0.0.0 will be run, and no updating will occur.

That's it!

Your application is now automatic-update-enabled.

Important information

When you distribute your application to your users, simply give them the Bootstrap application instead of the "real thing", and they will always receive automatic updates. You can even deploy your applications to your users through this method - no need to have them download your large application all at once. They can download the bootstrap application, and it will download the rest.

Points of interest

DDay.Update is in mid Beta testing. If you see anything strange or unexplained, please let me know by submitting a bug report here.

Share

About the Author

Doug has been a Software Engineer for 7 of the previous 9 years, and has 12 years of programming experience.

For the past 3 years, he has been developing custom applications in C# and Visual Basic.NET, with an emphasis on custom cross-Internet applications for IT management, real-time collaboration, and process management and reporting.

Comments and Discussions

I've implemented an update method for Windows Services, but it's only been very lightly tested. In this case, you'd have a bootstrap for your main application, and also setup your Windows Service to auto-update. This means you'd be publishing 2 separate applications. Your Windows Service wouldn't have a bootstrap (since it's a service, after all), but the update process I've established seems to work. You'd need to make sure the Windows Service runs on an account that has privileges to modify files in the directory where the service resides. Check out the DDay.Update.WindowsServices and DDay.Update.WindowsServices.ServiceUpdater projects from the code trunk in SVN for more information on how this is done.

I was wondering if it were possible to apply this to multiple projects in the same solution? If so then how? Would this have something to do with the deployment of the solution. ex. I have proj1 and proj2 contained in a solution in VS2005 and I want to deploy them together at the same time I want to update them as the files are changed. Would I have to create separate bootstraps for each application?

I usually deploy a single project that references multiple .dlls (i.e. projects). When you deploy that project, it also deploys information about these .dlls so they can be properly updated as well. You only want a bootstrap for concrete (runnable) applications.

I do the same thing as far as creating libraries and assemblies, however, in this one instance I have two separate projects that are executables (not dll's). I was thinking that maybe I could create the bootstraps for both and then create a setup project that includes the bootstraps and so, once the user runs setup project the first time, he or she will then have the bootstrap versions and they will auto-update each time from that point on.

Where in the source code or in options you can change the name of the directory where the files are downloaded the new version?For example: "C: \ MyAppBootstrapFolder \ 0.0.2.8 \ ..." replace with "... \ C: \ MyAppBootstrapFolder \ NewVersion \ ..."That is, the directory is entitled "... \ 0.0.2.8 \ ..." I want to change the name to "... \ NewVersion \ ..." How to do it?

Thank you for your reply! Help me please with code section, which is responsible for stamping of destination folders with the version they represent. So in which sourse file and which method is responsible for this action?

I've given you sufficient information to do what you're asking yourself. I'm not going to go through every single line of code that needs to be changed just because you "have very little time to solve this problem."

Hi!I started the solution DDay-Update-0_72_1 in MS Visual Studio 2010, completed the conversion and the properties of each of the projects in the Application tab in the dropdown list "Target Framework:" selected item ".NET Framework 4", then performed the Build Solution. Testing showed that everything works well.But I found the problem is that updates are performed full version software, which is bad for those projects that take up space on your hard disc.

Is it possible to configure updates for individual files that have changed and not for all the software completely? And what way? If you have not provided it in the source code, in which section best finish writing code that will compare files and update only those that have changed in the new version of the software?

No, DDay.Update doesn't perform a full update every time. It detects which files need to be updated based on the manifest file that's generated when you publish your ClickOnce application. This involves the following comparisons:

1. File version - if the new file has a different version than the old one, then update it. Note that not all files in the manifest have a version.2. File size - if the new file has a different size than the old one, then update it.3. SHA-1 hash - if the file sizes are the same, then a SHA-1 hash is performed to detect changes.

Is there an example you can give (i.e. manifest files) where these checks aren't happening like they should?

Currenly i have developed application on .NET Framework version 4.0, but when I generate bootstrap, I get an exception that can not load file or assembly "PresentationFramework, Version = 4.0.0.0, Culture = neutral, PublicKeyToken = 31bf3856ad364e35" or one of the dependent components. Unable to find specific file. Please help me.

Hi,When i look at detailed information of DDay.Update.Dll, i see copyright is to Daywest Manageemtn Inc. Your website shows that you have been working at the company.Is this ok to include this file in my application?