.NET Updater Component
I really think the self-updating component is pretty neat, and I plan to play with this feature over the weekend. However, I'm curious about the need to download all files when a new version is released.
Version 1.0.0.0 of the app and 1.1.0.0 of the app seem to be using the same AppUpdater.dll (same version, etc). I know this seems small for the TaskVision app, but if you are deploying an app with several third party components you wouldn't want the client to d/l all that again if nothing has changed. I could have written an app with 3MB of DLLs and only 1 has changed. Is there a way around d/l all 3MB if only 1 DLL has changed?
Thanks in advance for your thoughts and comments.
it has to do with the fact about running the application offline. if you only download part of an app, it won't work offline.
as mentioned in another place in this forum (don't remember where offhand), this sort of thing will be a feature in a future release of .NET. And I'm pretty sure you will be able to specify how you want it to download your app, but will be all of it by default.
as for getting the appupdater to do partial downloads, i'm not sure, i haven't played around with it enough yet, but like you, i will be playing with it this weekend. i'll let you know if i find anything...hopefully someone else knows the exact answer.
Having worked with the AppUpdater component over the last two months in a commercial prototype, I have become very familiar with its internals and made a lot of modifications to it. This is how an update works:
1. An update is detected (in my case by a polled call to a web service).
2. A download is initiated (either automatically, or after prompting the user).
3. A temporary folder, named "AppUpdate", is created at the same level as the current working one.
4. The new and/or changed files are downloaded into this temporary folder. If only one file has changed, it is the ONLY one downloaded.
5. An exact copy of the current running folder is created, and named with the new update version (e.g. "1.1.0.0").
6. The new files in the temporary folder are copied into this new folder, thus overwriting any existing older versions.
7. The temporary folder is deleted.
8. The "AppStart.config" file is updated to point to the new folder ("1.1.0.0").
9. The next time the application starts, the new version runs.
There are also phases in which previous update versions are "scavenged", and in which downloaded DLLs are verified with strong names.
In my case the AppUpdate has been extended to support dynamic updating, or downloading of files directly into the current running folder without requiring a restart. This is especially useful for non-executable files such as read-only data files containing lookup tables used by the desktop application. I call this process "correcting" rather than updating, which implies new functionality, and rather than patching, which implies bug fixing.
One limitation of the AppUpdater component that I had to rework for my implementation is that it determines the current application version from the version of the application's startup assembly. I found this to be unsatifactory because this assembly may not change from update to update, and does not work for my correction feature. I added a version element to the "AppStart.config" file.
Overall the AppUpdater component is an incredible piece of software, and it very successfully represents the paradigm shift from clumsy web-based applications to auto-deployed smart clients. Once the .NET framework is as pervasive as, say, the VB runtime, or IE, costly and awkward (browser page-based) ASP/ASP.NET applications will give way to ruch desktop clients that are easy to write, provide a dynamic user interface, update automatically, integrate well with the user's environment (printing, other apps, etc.), and cut down on the need for vast web farms.
