Groups | Blog | Home
all groups > dotnet distributed apps > november 2003 >

dotnet distributed apps : Updater Application Block



Ice
11/14/2003 7:12:44 AM
All -

Just curious to know how (and if) anyone has gotten past the fact the
Updater Application block downloads "all" client assemblies during an
update.

Thanks.

Ice

devillejeff NO[at]SPAM hotmail.com
11/21/2003 9:18:22 AM
Could you set up the manifest to only include the new files, and then
include a post-processor to copy the other files into the new
installation directory (from the client itself.) Using the copy
functionality should avoid file locking issues (I think) and though
you'll have a cluttered directory of duplicated files on the client,
the updater will clean them up on the next load.

I was either going to try this, or since I'm developing internally,
dynamically writting a batch process that uses robocoy and executing
it in the background.

Has anyone already tried this?

-jeff


[quoted text, click to view]
Ice
11/24/2003 9:09:33 AM
This sounds like it could work.

I don't understand what you mean by the "updater will clean them up" It
seems to me that you will have to write some program that actually manages
the filesystem outside of the updater.

ice
[quoted text, click to view]

Bill Sabey
1/6/2004 8:00:29 PM
Has anyone had a chance to do partial updates yet? Mind sharing what you
did? This is very desirable.

[quoted text, click to view]


n33470 NO[at]SPAM yahoo.com
1/7/2004 6:04:04 AM
[quoted text, click to view]

I'd like to follow this thread. We'll need to do exactly the same
thing on our project.

I've prototyped the use of the updater in our application, but so far
I've just been using the "download everything" approach. I haven't
gotten around to coding the "download just the changes" approach, but
I have an idea on how to do this. I was thinking that after the
manifest is downloaded, and an updated version is detected, the first
thing to do is copy the entire "current" directory to the new "temp"
directory. Then the downloader would look at the manifest file and
download the changes in the "temp" directory, which is exactly how the
updater works out of the box. From here on out, the updater works
just as it does today. The only extra step that needs to be
designed is copying the contents of the current directory into the
temp directory.

Does this design make sense? Is it the best alternative?

Any other ideas?

Bill Sabey
1/7/2004 10:46:01 AM
Another approach may be to use the postprocessor since there is an interface
we can use. If the server has the changed-only files, the download places
these in the new directory. The postprocessor could then go through the old
directory copying all files not in the new directory. I haven't looked to
see how easy it is for a postprocessor to have access to the old directory.

[quoted text, click to view]

rs220
1/20/2005 7:43:19 AM
I've got something working with the postprocessor to allow for
incremental updates. There are several things I need to clean up, and I
need to add a "backup plan" that would revert to the old version if
there is a problem copying files, but it works. My starting point was
the SelfUpdating Quickstart. The AppStart exe launches my "real"
application which is nested in a folder named after the version number.
The "real" app contains the code to launch the updater. Basically, I
added a parameter to the AppStart config file called "previousVersion."
In the postprocessor, it grabs the base directory for AppStart, and
appends the previousVersion number on the end of the path as the source
folder, and uses installedVersion for the destination path. A function
then copies files and folders from the old version folder recursively
(if they don't already exist in the new version folder). At some point
I can post some code, but there are MANY areas of the app where
customization has occurred, so eventually I'd like to zip up the whole
app as an example. FYI: I also converted all absolute links to relative
links in the config files and code, so we never have to rely on the app
being located where we "think" it will be on the user's drive. To be
continued...
AddThis Social Bookmark Button