How to Design/Develop an Auto Update System Like Windows Update

[lmttag]

Hello,

First off, let me apologize if I’ve posted this message to the wrong place.
I’m not really sure where to post such questions. If anyone knows of a
better, more appropriate place, please let me know.

Anyway, on to my situation... I am part of a software team that develops a
suite of custom applications. Our suite of applications has been around
awhile and has grown in number and progressed with newer technologies. As
such, we have applications written in Access (updated to Access 2007 and
compiled to MDEs), VB6, VC++, VS 2003/.NET 1.1, and VS 2005/.NET 2.0. We
have COM DLLs and OCXs that need to be registered/unregistered, Windows
services, and an ASP.NET web site (that runs on the same server as all the
other software and is only an intranet application). Finally, we have a SQL
Server database backend that is created and updated using a set of .sql files.

The reason I mention all this stuff is that we also developed our own custom
setup or installation program. We developed a C# Windows Form application
that takes care of everything – copying and deleting files,
registering/unregistering DLLs, OCXs, services, etc., writing registry info.,
creating shortcuts, etc. We don’t use InstallShield or Wise or any other
installer. And, everything works great. But, now we want to take the next
step and provide automatic updating capabilities.

Therefore, we are needing to create some sort of automatic update
application (like a Windows Update) that can determine what software has been
installed, what patches have been installed, what’s needed to upgrade the
system to the latest software, download the necessary patches, and install
everything. The problem is I’m not sure where to begin to figure out how to
develop something like that.

- Can anyone provide any information on developing a automatic updating
system?
- Has anyone done such a thing?
- I’ve searched the Internet but haven’t found much useful stuff yet. Does
anyone know of good resources to read/study?
- How did Microsoft design and develop Windows Update?
- What kind of architectural “things†need to be considered?
- How would you handle dependencies on other applications and/or versions of
things?
- How would you handle order of installation?
- Etc., etc., ...

Because we have a variety of application types (as described above), we
can’t really use anything like ClickOnce. And, we’re definitely not wanting
to use a 3rd party product like InstallShield. We’re needing to design and
develop our own custom solution.

As you can see I’m at the beginning of trying to figure this out and have a
lot of questions. I would greatly appreciate any guidance and information.

Thanks!

Feel free to e-mail me at: yogrraps _at_ yahoo _dot_ com

 

[Marc Bernard]

Hello,

Therefore, we are needing to create some sort of automatic update
application (like a Windows Update) that can determine what software has been
installed, what patches have been installed, what’s needed to upgrade the
system to the latest software, download the necessary patches, and install
everything.  The problem is I’m not sure where to begin to figure outhow to
develop something like that.

We built something on top of an early release of the Microsoft
Application Updater Block.

http://msdn.microsoft.com/en-us/library/ms978574.aspx

Marc
http://nomagichere.blogspot.com

 

[Larry Smith]

You should try to use ClickOnce.

ClickOnce is extremely limited so it's impractical for all but the most
simple installations. For example (in no particular order), you can't
customize your installations which is reason enough to avoid it (you can
only perform start-up initialization the first time your app runs), you
can't pass arguments to your application on the command line (there are only
URL-based parameters which is useless here), there's no effective control
over the Start Menu entries it creates, you can't silently uninstall, the
installation is always per-user, there's no facility to add a license
agreement, there's no facility to create a file (extension) association in
2.0 (this was finally added in 3.X), and so on. There are dirty ways around
some of these things but in practice there are a lot of serious limitations
with this technology (leaving one to wonder why MSFT would release it this
way).

 

[Larry Smith]

ClickOnce may not _automatically_ support all of the things you mention,

but there's nothing it can do to _prevent_ an application from providing
custom code to do whatever that application wants to. In the worst-case
scenario, each new version deployed would simply check to see if it's the
first time executed, and at that point go through a custom, non-ClickOnce
setup implementation. ClickOnce would simply be the trigger, not the
actually install implementation.

It really defeats the purpose however. You gain automatic installation and
update capabilities so long as you roll your own installation and updates.
You also wind up supporting two different installation technologies
(ClickOnce and probably MSI). That's the only practical way to do it in any
case (there's an "IsFirstRun" property in fact), but using native ClickOnce
by itself, you can't even do any "pre-installation" processing outside of
some simple prerequisite checking (using an XML-based bootstrapping
mechanism provided by MSFT - intended primarily for installing
prerequisites). You can't prompt the user for any installation information
up-front for instance nor check the environment without using this
bootstrapping mechanism (which is unwieldy and inappropriate depending on
your needs). Nor can you carry out any processing required before the first
run (that the install program itself should have taken care of). Take
something as simple as adjusting the Start Menu for instance. Unless the
ClickOnce app automatically starts the first time it's downloaded (this can
be setup up by the programmer), the user's first run will be via the Start
Menu (note that the ".exe" itself is even hidden from the user so they can't
start it from Windows Explorer or the command prompt). The first-time code
may need to adjust the Start Menu however so on the first run you have to
rely on ClickOnce's default set up of this menu. IOW, the user sees the
Start Menu one way when they first launch the app and then differently
thereafter (since your first-time code will change it). Moreover, even if
you wait until the first run to conduct initialization, the user may not
have admin rights to carry out first-time processing if req'd (nor do you
want to continue the installation anyway - it was supposed to have already
been installed). Note that the first-time code won't run again after that
however (until the next ClickOnce update) so you only get one shot at it
(unless you manually check things yourself on every run). This all gets very
messy which is I why I question MSFT's decision to release it this way.

That said, I readily agree that ClickOnce might not be the most efficient
or appropriate way. I'm just saying that the OP should rule that out
themselves after careful consideration, rather than just assuming that
because ClickOnce doesn't inherently support their use case, it's
impossible to take advantage of it.

I agree (in spite of my rant) but he needs to carefully research it. Even if
it does what he wants now (by performing a shotgun marriage with his own
technology), he needs to ensure there won't be any problems later (which is
almost a given if any customization is ever required).