Self-updating windows service application (can't use ClickOnce?)
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?
Andy
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?
Andy
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Greg,
I'm still stuck on other ways to update the installed host service, however I thought you might be interested to see this:
http://www.gotdotnet.com/codegallery/messageboard/thread.aspx?id=83c68646-befb-4586-ba9f-fdf1301902f5&mbid=12cb6ded-7a11-4569-b862-a544b676baa8&threadid=9ee79bb9-2ab0-41e7-9e80-cc0e462f348a
Apparently MS are looking to release the UAB for .NET 2.0. I think a combination of the UAB and the hosted AppDomains could be very powerful. I'd be interested to know what you think about it, especially in relation to updating the physically installed service.
Andy
I'm still stuck on other ways to update the installed host service, however I thought you might be interested to see this:
http://www.gotdotnet.com/codegallery/messageboard/thread.aspx?id=83c68646-befb-4586-ba9f-fdf1301902f5&mbid=12cb6ded-7a11-4569-b862-a544b676baa8&threadid=9ee79bb9-2ab0-41e7-9e80-cc0e462f348a
Apparently MS are looking to release the UAB for .NET 2.0. I think a combination of the UAB and the hosted AppDomains could be very powerful. I'd be interested to know what you think about it, especially in relation to updating the physically installed service.
Andy
well the issue with the service will always be your root domain (making another process generally is a bad idea)
When I did mine, my actual service had all of about 10 lines of code in it so I didn't really worry too much about it.
I will have to think about this for a few ... off the top of my head I could see you updating the .dll and assigning a step on the next reboot (to copy the new assembly before the service starts)
When I did mine, my actual service had all of about 10 lines of code in it so I didn't really worry too much about it.
I will have to think about this for a few ... off the top of my head I could see you updating the .dll and assigning a step on the next reboot (to copy the new assembly before the service starts)
ASKER
Greg,
Its amusing, I feel like I'm always pushing the problem one step further down the line. The problem with the windows services is obviously that you need a way of updating and then stopping and restarting. Possible solutions include another process to do the update, as you said above (do you have any particularly strong reasons that rule that one out) or another windows service to do the updates; but then who updates the updater :-).
So far, I think I'm making progress by having the host service contain minimal lines of code and kicking off a "master-service" AppDomain which handles the status reports; downloads from the web service; strong name verification; and loading/unloading/updating
If only there was an easy way for a service to restart itself...!
Andy
Its amusing, I feel like I'm always pushing the problem one step further down the line. The problem with the windows services is obviously that you need a way of updating and then stopping and restarting. Possible solutions include another process to do the update, as you said above (do you have any particularly strong reasons that rule that one out) or another windows service to do the updates; but then who updates the updater :-).
So far, I think I'm making progress by having the host service contain minimal lines of code and kicking off a "master-service" AppDomain which handles the status reports; downloads from the web service; strong name verification; and loading/unloading/updating
If only there was an easy way for a service to restart itself...!
Andy
the UAB did this with apps ... kept pushing it down the line until the had a simple loader app which cannot be updated.
having the service be a loader which simply spawned another process I would think would be a bit odd (for purposes of controlling it) it would also be misleading about whether or not the process had started successfully etc.
having the service be a loader which simply spawned another process I would think would be a bit odd (for purposes of controlling it) it would also be misleading about whether or not the process had started successfully etc.
ASKER
I was pondering more along the lines of having the service load a seperate process which would then close down the service, update it, restart it and then close itself down.
that could be done ...
ASKER
Greg,
I've been playing with the seperate process. Its looking good so far. In fact, it is pretty much what the UAB does in one of the update scenarios. Combining that with my AppDomains seems to be working; my implementation is a little different to the reference you posted though. Working out a distribution framework for the mounted services is proving fun!
I don't think I'm going to get any more participation on this question, so I'll close it and award you points for the discussion. Thanks for your input,
Andy
I've been playing with the seperate process. Its looking good so far. In fact, it is pretty much what the UAB does in one of the update scenarios. Combining that with my AppDomains seems to be working; my implementation is a little different to the reference you posted though. Working out a distribution framework for the mounted services is proving fun!
I don't think I'm going to get any more participation on this question, so I'll close it and award you points for the discussion. Thanks for your input,
Andy
ASKER
It might also interest people to know that UAB has just (this last week) been ported to .NET 2.0 to work with the Jan 2006 Enterprise Library.
Download (you have to sign in with passport and join the project to access the download):
http://www.gotdotnet.com/codegallery/releases/viewuploads.aspx?id=83c68646-befb-4586-ba9f-fdf1301902f5
Download (you have to sign in with passport and join the project to access the download):
http://www.gotdotnet.com/codegallery/releases/viewuploads.aspx?id=83c68646-befb-4586-ba9f-fdf1301902f5
ASKER
Have had a look at that today. Its very similar to what I ended up setting up while I was waiting on this question. I'm using AppDomains in a similar way, except my host service has basically no intelligence itself. It loads an appdomain which manages the other appdomains. My thinking was that it would be easy to not only update the hosted jobs (services) but to also update the host itself if it had a minimal interface to the installed windows service. Both the hosting and hosted appdomains use a manifest based ClickOnce/UAB-like web service update repository, but with the advantage of shared dll downloads etc. The hosted appdomains (and now the hosting code too) can still all report to a status web service about their current status, so it is looking good. It seems to be working, though with a few teething problems at the moment.
Given that this is really transferring the update problem from multiple services to a single point, i.e. you are able to update the hosted services/jobs, but you still to have an assembly that the windows service uses to talk to the hosting appdomain, I would be interested to know if you have any ideas about how best to implement and update the code used directly in the windows service's default appdomain.
Andy