Application updating

I'm hoping someone here can give me ideas, or at least point me in the right
direction.

Our application (under XP) is capable of downloading and installing updates
to itself. An XML manifest is stored on the server, which outlines all the
updated files. However, since the format of this file might need to change
over time, the application itself isn't qualified to read this file.
Instead, it uses a DLL. The DLL is always up to date (i.e. able to read the
file manifest) because the application first downloads the latest version of
the DLL from the server. It then invokes code in the DLL, which processes
the manifest, creates a list of files that need to actually be downloaded,
and returns control to the application.

Next, the application needs to exit, and allow the files to be installed
(one of which is invariably the application itself). This process is handed
over to another exe, which the application downloads the latest version of
as well. The installer reads the manifest, examines the downloaded files,
installs everything, and then re-launches the main application.

All of this is working under XP. When it comes to Vista, we obviously are
going to encounter some challenges.

The primary problem is that the application, which must run as a standard
user, has to somehow download a DLL and an EXE, and place them into
CSIDL_PROGRAM_FILES_COMMON.

Is there any way to do this? (At this point I'm just assuming that I
wouldn't be able to download them to anywhere outside of \Program Files and
still be able to execute them.)

Also, if I'm able to get the update installer exe written somewhere, will
the application (which is currently marked as asInvoker) be able to execute
the installer, which is marked requireAdministrator?

Thanks,
Dave

Hello,

<snip>
> The primary problem is that the application, which must run as a standard
> user, has to somehow download a DLL and an EXE, and place them into
> CSIDL_PROGRAM_FILES_COMMON.
>
> Is there any way to do this? (At this point I'm just assuming that I
> wouldn't be able to download them to anywhere outside of \Program Files
> and still be able to execute them.)
>

I'm afraid this isn't possible. Standard users cannot write to this area.

One solution I can think of is to create an "updater" service or a scheduled
task that handles all the logic for updating your application and is
completely seperate from your main application (accepts no input from the
app) - from requesting the difference file from the server to stopping all
of the running instances of your program and updating them.

Since it would run as a service, it will be able to work its magic in a
privileged context; and, since it accepts no input from "normal user" land
(other than perhaps an 'update now' command and settings such as how often
to check for updates), it wouldn't open any obvious security holes.

> Also, if I'm able to get the update installer exe written somewhere, will
> the application (which is currently marked as asInvoker) be able to
> execute the installer, which is marked requireAdministrator?

Again, I would suggest running the updater as a windows service or a
scheduled task. You could then begin an update process by starting the
task/service, or using some form of IPC.

Note that the update installer would need to be able to work without showing
a GUI and use IPC to report errors to your program.


--
- JB
Microsoft MVP - Windows Shell/User

Windows Vista Support Faq
http://www.jimmah.com/vista/

Thanks for the reply. I've come up with a solution that, thus far, seems to
be working. As mentioned in the original message, the majority of the
updating procedure is already carried out by an external program, so that
bit hasn't changed.

What I did was to allow the main program to have an option of where it loads
the external program from. If the update programs aren't located in the
common program files folder, or if new update programs are available, the
main program will download and execute the update program from the user's
private folder. In this case, the updater is told by the main app that it's
a new version, and it copies itself (and the other update helper tools) to
the common program files folder, such that the next application requiring to
update itself can find them in the expected location.

So far this is working well on my dev environment, with only some minor
problems here and there. But overall, this is a workable solution. It only
presents a single escalation prompt, and doesn't require installing a
service of any type.

Thanks again,
Dave





"Jimmy Brush" <JimmyBrush@discussions.microsoft.com> wrote in message
news:1104B471-6320-4B0E-9657-4D82D4205457@microsoft.com...
> Hello,
>
> <snip>
>> The primary problem is that the application, which must run as a standard
>> user, has to somehow download a DLL and an EXE, and place them into
>> CSIDL_PROGRAM_FILES_COMMON.
>>
>> Is there any way to do this? (At this point I'm just assuming that I
>> wouldn't be able to download them to anywhere outside of \Program Files
>> and still be able to execute them.)
>>
>
> I'm afraid this isn't possible. Standard users cannot write to this area.
>
> One solution I can think of is to create an "updater" service or a
> scheduled task that handles all the logic for updating your application
> and is completely seperate from your main application (accepts no input
> from the app) - from requesting the difference file from the server to
> stopping all of the running instances of your program and updating them.
>
> Since it would run as a service, it will be able to work its magic in a
> privileged context; and, since it accepts no input from "normal user" land
> (other than perhaps an 'update now' command and settings such as how often
> to check for updates), it wouldn't open any obvious security holes.
>
>> Also, if I'm able to get the update installer exe written somewhere, will
>> the application (which is currently marked as asInvoker) be able to
>> execute the installer, which is marked requireAdministrator?
>
> Again, I would suggest running the updater as a windows service or a
> scheduled task. You could then begin an update process by starting the
> task/service, or using some form of IPC.
>
> Note that the update installer would need to be able to work without
> showing a GUI and use IPC to report errors to your program.
>
>
> --
> - JB
> Microsoft MVP - Windows Shell/User
>
> Windows Vista Support Faq
> http://www.jimmah.com/vista/