Lets suppose I have an .NET client application that connects to a WCF service, or perhaps a message queue. During the normal execution of the program it is possible that there might be connection losses or maybe the user has been forced to log off by the administrator, or the administrator sends a message to the app to change and login to another WCF server (e.g. some form of manual load balancing).
The client application would only know about this when any one of many low level methods ties to make a WCF call and it fails.
When such a thing happens I’d like the application and all its windows to somehow be disabled/hidden, for a dialog box / splash window to come up and do a reconnection, and once successful the windows get shown again.
How does one go about doing this? The problem I see is that the code which first finds out there is a problem is at the lowest level (i.e. maybe as a result of a button click on a dialog window that is on top of main windows). Sort of need the program to be inside out to handle it intuitively. Therefore I am assuming there are some patterns or frameworks that help with this?
Unfortunately there isn’t a great way of doing this because the exceptions caused by it are going to start anyplace a WCF call can happen and go upward until something catches them. For the HTTP bindings you know when that will be because WCF only does anything when you make an explicit call, so you could catch any disconnect/timeout exceptions and deal with them appropriately.
For message queues or TCP bindings I think it might get a bit messier, but the tactic is the same. Anytime you’re making a WCF call, you’ll need to watch for the appropriate exceptions and then the application will have to call some function that can change the UI how you want.