I got a number of great questions in last weeks launch tour. One of those questions was a general need to understand how the various dependency analysis features in VS 2010 Ultimate worked vis-a-vis WCF services, and whether there was support for walking across the service boundaries to discover further dependencies on the other side.
The short answer is “No”. How’s that for short. :)
The analysis that we are doing to determine dependencies as well as call information when generating the Sequence Diagram from code is all done statically. That means we are not going to pick up types that were loaded up dynamically at runtime, nor are we going to be able to walk across a service boundary, given how complicated endpoint configurations can be. Dynamically loaded types that are “injected” at runtime is high on our product backlog for next version, but walking service boundaries is not.
The main design principle behind the tooling you see in VS2010’s visualization and modeling tools is the need to understand your existing system’s current dependency “web”. The idea being that in many of the systems we’re seeing out there, dependency management is difficult, and as a result, dependencies are a mess in many of those applications. We wanted to give you some tooling to help deal with that mess. That mess is generally due to the inability to understand how one piece of code can adversely impact a piece of code somewhere else in the system due to complicated dependency coupling more than one or two “hops” away. So we prioritized dependencies that we could discover statically. Next priority is pull in runtime analytics so dynamically loaded types and the dependencies therein can be reasoned over. Then sometime after that, service boundary dependencies.
We prioritized this way ‘cause we learned that most shops out there aren’t doing anything explicit about dependency management, such as leveraging an IoC framework. So we wanted to optimize for the larger issue.
All that said, it isn’t as though folks using IoC frameworks or services don’t have dependency problems. But the problems for them are probably not at the boundaries they have explicitly addressed, but more internal to the subcomponents they are injecting, consuming, etc.
Hope that makes sense. :)
Regardless, what does running Sequence Diagram RE over a WCF client look like? Take a look at the following picture, created by right-clicking in the Main() method of the client code of a very simple WCF client. ( Check out this very simple tutorial for WCF ).
You’ll see that the calls stop at the contract of the service. CalculatorClient is simply a proxy created with the ServiceModel Metadata Utility Tool ( Svcutil.exe ). We do not grovel across that boundary to analyze calls on the actual implementation side of the service.
Another way to look at this is via the DGML Assembly Graph, shown here:
Notice that there is no link between the “Service.Exe” assembly and the “Client.Exe” assembly.
Hope that helps,