My SqlDependency works fine, and the Broker Queue and Service get dropped properly when the application exits (I do execute SqlDependency.Stop(...) as recommen
This is the normal behavior. QN are long lived and they will fire upon a database restart (thus also will fire after a Server restart). But SqlDependency
sets up a temporary service/queue to receive the notifications and these are supposed to be tear down in case of crash by using a dialog timer and internal activation. The way these two mechanisms interact is what you see, the ERRORLOG pollution. Nothing bad happens, at least not usually, but is obviously not neat.
Can things be made neater?
You can roll your own solution using directly SqlNotificationRequest which no longer provides the 'services' of creating a service/queue to receive your appdomain notifications and route them to the appropriate SqlDependency.OnChange
event. There are viable alternatives, depending on the exact scenario. But is fairly low level work and you may end up solving the problems in a worse manner than the original SqlDependency
solution...
BTW there is no way to 'drop' the pending QN subscription on application exit. The problem is inherent in the one-way dialogs used as notification delivery mechanism by QN. Proper notifications (subscriptions) should be initiated by the subscriber and the notification should be a response message from target (notifier) back to initiator (subscriber).