When a MEF-activated brokered service is activated over a pipe, the ServiceActivationOptions.ClientRpcTarget property was always null, even when the service-side descriptor calls for a target proxy.
The creation of the proxy back to the client is the responsibility of the MEF implementation of IServiceBroker. But the service broker only knows how to create it by looking at the descriptor. And the descriptor is only available after activating the brokered service, because it is an instance property on the MEF part that implements the brokered service. But by the time the MEF part is activated, its imports (including of ServiceActivationOptions) must have already been satisfied. So we have a chicken-and-egg problem.
To resolve it, we create the brokered service, but before fully initializing it, we get its descriptor, and if it requests a client proxy we dispose of that brokered service and re-activate it with a modified ServiceActivationOptions that includes the proxy.
While it feels odd to activate, dispose, and re-activate a brokered service for one client request, I don't see a better way. And it shouldn't be a breaking behavioral change because it only impacts brokered services that would have been broken before on account of not getting the client proxy they were expecting. So I see this as enabling a new scenario. And technically, the calling pattern has always been a possibility (say, a botched activation followed by a successful one), so it shouldn't be a problem.
When a MEF-activated brokered service is activated over a pipe, the
ServiceActivationOptions.ClientRpcTargetproperty was always null, even when the service-side descriptor calls for a target proxy.The creation of the proxy back to the client is the responsibility of the MEF implementation of
IServiceBroker. But the service broker only knows how to create it by looking at the descriptor. And the descriptor is only available after activating the brokered service, because it is an instance property on the MEF part that implements the brokered service. But by the time the MEF part is activated, its imports (including ofServiceActivationOptions) must have already been satisfied. So we have a chicken-and-egg problem.To resolve it, we create the brokered service, but before fully initializing it, we get its descriptor, and if it requests a client proxy we dispose of that brokered service and re-activate it with a modified
ServiceActivationOptionsthat includes the proxy.While it feels odd to activate, dispose, and re-activate a brokered service for one client request, I don't see a better way. And it shouldn't be a breaking behavioral change because it only impacts brokered services that would have been broken before on account of not getting the client proxy they were expecting. So I see this as enabling a new scenario. And technically, the calling pattern has always been a possibility (say, a botched activation followed by a successful one), so it shouldn't be a problem.