Here are my requirements:
1) To maintain an existing set of .NET 1.1 windows services that are part of our distributed application.
2) To add urgently needed functionality to these services in .NET 1.1, and distribute two new windows services to the workstations running the application.
3) To lower the time needed to maintain the multiple installations of each of these windows services.
4) To fulfil these requirements with consideration for an imminent port of our application to .NET 2.0 from .NET 1.1 - we don't want to have to spend time implementing self-updating code which will have to be completely rewritten, or scrapped, in .NET 2.0.
5) To continue to provide a low-effort maintenance regime for the upgraded .NET 2.0 services.
I realise that .NET 1.1 to .NET 2.0 is not just a minor upgrade and I shoudn't expect a smooth upgrade path. Given that the new functionality is desperately needed and will potentially involve a fair bit of maintenance before the .NET 2.0 port is complete, manually updating the services on the user machines is a long way from an ideal option. I have looked at both the .NET application updater component (http://windowsforms.net/articles/appupdater.aspx
) and the Updater Application Block 2.0 (UAB) which plugs in to the June 2005 Enterprise Library. Both of these would seem to offer a way to enable automatic self-updating windows services in .NET 1.1.
Apparently, however, the UAB is no longer supported in .NET 2.0. It is "replaced" by ClickOnce. While I love ClickOnce for smart clients it seems like it can't be used for Windows Services - what is the migration path from the UAB for windows services? Can I in fact use the UAB succesfully for windows services in .NET 1.1? Having done a fair bit of research it would seem like I can use the UAB, but then there is no upgrade path to .NET 2.0 from this. I have seen it written that the UAB can't be simply ported to .NET 2.0 due to "changes in the threading model" - is this the case?
So what are my options?