Non Desktop Application Updates

Topics: Updater Application Block
Jun 2, 2004 at 10:42 PM
originally posted by: StephenHaeney

Is there any way that this technology can be expanded to cover non-desktop applications, such as services?

I am looking at ways to keep a distributed enterprise up to date, but the deployed applications include SQL Server instances, Windows Services and Web Sites. I am not interested in updating the operating system, but would like to implement a consistent way of managing all the components of the deployed system.

So my question is could the Updater Application Block be developed to
1, Run SQL Scripts against a DB
2, Update Windows Seervices
3, Update a .NET Web Site

Thanks
Jun 3, 2004 at 11:36 AM
originally posted by: CyberGeek

Hey Stephen,

I'm currently working on a project that involves updating DLLs, Services and SQL Servers. As it stands, I use a console interface to run the updater, but I'll soon be changing this to be an Updater Service so that it's completely automated with no desktop login required. As for websites, you should have no problems updating any sort of HTML, ASP or ASMX pages.

Things to think about:
- If all 3 components are dependant on each other, you'll need to think of some sort of RollBack operation in case an update to one of the components fails (ie: you should treat the update as a single transaction)
- Services will need to be shutdown before they can be updated and restarted when the update finishes. (this actually goes for all Assemblies, ie: all applications using an assembly will need to be shutdown)
- If you're using BITS, BITS requires that a "logged on session" be used to run the Updater. So if you're running the updater as a Service, you'll need to run it under a Service Account (refer to http://msdn.microsoft.com/library/default.asp?url=/library/en-us/bits/bits/service_accounts_and_bits.asp)

Larry
Jun 3, 2004 at 9:43 PM
originally posted by: StephenHaeney

Hello Larry,

Thanks for the info.

The updates I am planning to roll out are not patches, but new versions of the software, so I expect that each new version will contain changes to most of the software components. My software is installed under a root directory “C:\Program Files\Tellermate\TICECentral”. I was considering implementing a computer-wide controller service and rather than having a version for each individual component, I was thinking about putting a version directory ( such as “1.0.0.0”, “1.1.0.0” etc ) under here and redeploying all the files that make up the release into a new directory.

Therefore, I should have no problem at all with busied files, at the expense of the extra disk space requirement and time to download the new versions.

You mentioned stopping the services before they can be updated. I understand that I can use the Post Processor to restart the service at the end of the install, but how would you stop the service before performing any update? I was planning to use Installutil to remove/install the service as part of the post process.

Does this sound ok to you?

Thanks,
Steve

Jun 4, 2004 at 4:52 AM
originally posted by: StephenHaeney

I should also have mentioned that I am trying to come up with a way to make this some kind of "Push" model as the client machines are seldom connected.

My thoughts are that I will initiate a dialup connection from the centre, to each client in turn, and somehow kick the Application Updater into life while leaving the connection open. I expect the Updater to collect the relevant files from the central location.

Once the process is complete, I will then pull the manifest back from the client in order to update a local database with the application version. This is to satisfy one of the design goals of being to easily report on installed software versions over the whole estate.

I do not really feel comfortable with this architecture, it feels all wrong. Any suggestions would be greatly appreciated.
Jun 4, 2004 at 5:14 AM
originally posted by: CyberGeek

Hey Steve,

So if you're not patching the files, then you can probably run the Service Uninstall-Install all in the Post Processor, as you mentioned, without having to stop the Service before the update happens. You would probably do the following:

1) Get a list of Services using the System.ServiceProcess.ServiceController.GetServices() and find your Service.
2) To stop it, you can call <YourServiceController>.Stop() (assuming you need to stop it before you Uninstall it). To uninstall, I guess you'll need to find the Assembly of the old Service and call InstallUtil to uninstall it. Since you create a new directory for each version, you'll need somehow figure out the old version's directory.
3) Install the new Service using InstallUtil. Make sure you specify all the Service Account information in your Service's Installer so that the Account Username/Pwd dialogue doesn't prompt you when you install.

Good luck...
Larry


PS - I'll get back to you regarding your last post if I think of anything