Learn to use Visual Studio, Visual Studio Online, Application Insights and Team Foundation Server to decrease rework, increase transparency into your application and increase the rate at which you can ship high quality software throughout the application lifecycle
Visual Studio 2013 Update 3 CTP1 brings improvements to Code Map and Debugger Map that you have requested via various feedback channels (user voice and connect in particular). In this Blog post I'll present:
In Visual Studio 2013, we introduced Debugger Map, which provides a nice experience to present the call stacks, and even the call graphs from breakpoints into the debugger. A debugger map can also show traces from an IntelliTrace file, either collected standalone, or from Application Insights. If you are not familiar with Debugger Map please look at Map methods on the call stack while debugging in Visual Studio
In Visual Studio 2013 Update 2, we improved the experience with IntelliTrace by providing parameters directly on nodes representing call stack entries (see Enhancements to Debugging Exceptions with IntelliTrace in Visual Studio 2013). In Visual Studio 2013 Update 3, we go a bit further by improving the zoom experience.
Before this update, each time the user moved to a new call stack entry, for instance by stepping in the debugger through the code, using F10, or reaching a breakpoint after pressing "continue", the debugger map would systematical show additional call stack entries (this is still the case), but unfortunately it would also "zoom to fit" in order to represent the full graph. This could rapidly get un-readable if there were a lot of methods involved in the call stack, because too many nodes and links would be represented, and therefore they would appear very tiny. To solve this problem:
Until this update, you could add code elements on a code map, or request architecture dependency diagrams, and the nodes were colored and had icons, but the links were all grey. This did not help you understanding what they represented. Of course they represented dependencies but those are all kind of dependencies, such as inheritance between classes or interfaces, interface implementation between a class and an interface, calls between methods, field usage between a method and a field, etc … To actually see the categories that a link represent, you can hover the link, and look at the tooltip.
The following picture shows portion of a namespace from the Entity Framework open source project, as presented before Visual Studio 2013 Update 3 CTP1
Here is the same picture after Visual Studio 2013 Update 3 CTP1. As you might see, this diagram is more understandable, provided I explain a bit what the colors represent.
let's have a look at the key for these colors, by clicking on the Legend button in the dependency diagram toolbox
The bottom of the legend show the following:
When there is a green link between EntityObject and StucturalObject, That does not mean that there are only inheritance, there are also method calls as well but these are hidden by the inheritance (There are method calls for sure because, in managed code if class D inherits from class B, then necessarily the constructor from class D calls the constructor from class B)
The green dashed links between EntityObject and IEntityChangeTracker means that EntityObject implements IEntityChangeTracker
The pink links between EntityObject and RelationshipManager means that EntityObject has methods which call methods in RelationshipManager, but there is no base/derived relationships between both. You may be wondering why we have chosen this pink color, this because it was close to the color of the method icon in the solution explorer or Class View, and also worked well in the light, blue and dark themes of Visual Studio.
The blue links represent references of fields by methods. This line is solid when the method writes the field, and dashed when the method only reads the field
All the other links remain gray. They correspond to method return types, or type references
If you are not interested in seeing the inheritance and method calls, but want to understand when there are field references, you can always disable the styles corresponding to Inheritance, interface implementation, calls by right-clicking on the styles and choosing "Disable"
The disabled styles will appear grayed out, and you will only see the colors corresponding to the styles which are enabled.
Note that this is not yet filtering, but that helps already understanding the dependencies better
The following picture shows the top-level architecture of the product code for Entity Framework Tools before the Visual Studio 2013 Update 3 CTP (I've selected the product code assemblies, and requested the contextual command "Show on Code Map")
From Visual Studio 2013 Update 3 CTP1 we get the colors as well: they represent the summaries of the individual links inside the assemblies, still using the same legend, and priorities of display
You will probably have understood it already. When I see a green dependency between Microsoft.Data.Entiry.Design.VersionningFacade.dll and EntityFramework.dll, this means that at least one class of the first assembly inherits from one class in the second assembly (or at least one interface in the same assembly inherits from one interface in the second assembly).
We also improved the Legend window, by adding entries for these links, changing the style from being a box (which did not make sense for links) to being a line
The styles for links could be added to the legend, but they would be represented by a square
And since the Legend Window can now become very big we have:
The last feature we have added to code map is the ability to drag & drop binaries from the File Explorer and start expanding the assemblies, or asking contextual questions about them.
Let's see 2 scenarios where you'd want to use this feature.
Let's say that I want to install on a build server the assemblies of corresponding to the Code Index SDK, and I want to understand if that will work or if this requires assemblies to be GACed on the server.
I can do the following:
You will get the following view
Note that we have not shown this here, but of course you can expand the DLLs that you dragged and dropped in order to understand their namespaces, types etc ..
Therefore you cannot normally deploy the Code index SDK DLLs without installing Visual Studio Ultimate … or installing the DLLs they depend on along with our 3 DLLs (if this is not a violation of the EULA)
The last scenario I will consider is the case where I produce DLLs that you want to group and ship in packages, for instance NuGet packages. You want to make sure that you don't have circular dependencies between your packages, and you want to understand what these dependencies are.
You will want to:
Let's suppose here I want to package the Code Index SDK along with its dependencies, I add natural parent groups (Code Index SDK, Code Index, .Net Framework, MsBuild)
Now let's suppose I've enabled the circular dependency analyzer:
And I'm tempted by moving the PEReader.dll assembly part of the Code Index SDK
If I do that, the Circular Dependency Analyzer will turn red the groups which are implicated in a cycle, and the offending dependency links).
When you have discovered unwanted dependencies, can study what's causing the dependency in more detail, by right-clicking on a link and requesting Advanced | Show Contributing Links on Code Map
As always, we are interested in hearing your feedback on this feature. Please try it out, and let us know
Give me a free ultimate licence and I will provide all the feedback you need!
This policy of having everything going into Ultimate editions just doesn't cut it...
My company only buys the Pro version licence so yeah...
Agree Jorge, feel for you.
Surely VS team (or down to the marketing head?) can find a modern way of charging people for using their product? Probably a VS 365?
I have Ultimate, and use the debugger code map.
However, I don't really use the code map outside the debugger (say for exploration) because it is simply too slow: I was hoping one of the improvements I'd see here would be "amazing performance improvements" because it's beautiful and very clever, but just too slow.
I wonder how many Ultimate licenses Microsoft sells. My assumption is it is a small percent versus premium and pro. I wish Microsoft (and my they have) would look at re-pricing premium and pro and see if they can get the same revenue through volume.
Please at least tag Ultimate posts with Visual Studio Ultimate. We have 150+ developers and the cost for VS Premium with MSDN is already pretty steep, the cost to move to Ultimate would almost triple that. Every time we see a post about a great new feature in VS, it is guaranteed to be Ultimate only.
Our SAAS solution with it's various myriad licenses for Win And SQL already brings a ton of $$ in every year for Ms, please lower the Ultimate licensing costs, we would love to use these new tools.
These features should be in Visual Studio Premium.
I really think Ultimate should be dropped as a SKU, many of the features in there should really be used by most professional developers, not just folks with deeper pockets.
How many Ultimate users are actually paying the full price? I have only seen Microsoft employees actually use the thing, and I applaud the (few?) developers who can talk their employers into paying almost triple on what is already a steep price for what basically amounts to nice-to-have features. But I sure wouldn't mind to have access to them.
It's telling how almost all posts about nifty VS features end up in a frustrated discussion about Ultimate. Should tell you something.
Come on, drop this Ultimate silliness for VS2015.
me too. The ultimate is to expensive.
I understand the Price with TFS. But this ist a single developer Feature.
well ive got it for free I guess just keep using the trial version over and over again lol