This blog post was updated in Dec 2016 to explain what changed with Visual Studio 2017. More in: The visual Studio Modeling SDK is part of Visual Studio 2017
In Visual Studio 11 Ultimate, the experience around the architecture diagrams has improved a lot, with respect to Visual Studio 2010. In particular, performance and scalability are much better than they used to be, as we mentioned already. It is also possible to create dependency diagrams using the solution explorer, and then ask questions from the representations of the code elements in the diagram.
At the heart of these improvements, is the Code Index which is a SQL server localdb database. Each time a diagram representing code elements is built, the corresponding assemblies are indexed in the code index (if they need to be). that is then used as a cache to query all the needed information. In the Architecture diagrams, the information which is indexed is limited to what is in the solution, but it is possible to pre-populate the cache using build tasks, and to leverage the information which is in the cache, as well as creating new contextual commands.
I’m starting here a series of posts that will explain some of the scenarios which are enabled with the code index SDK and then show how to:
- Install the Visual Studio Visualization and Modeling SDK in which the code index SDK MsBuild tasks are located
- Bulk index assemblies
- Use indexed data
- Parameterize the code index settings (advanced)
1. Why would you want to use the code index SDK?
The code index is used, internally in Visual Studio. But it also opens-up opportunities for the ecosystem. This paragraph presents some of the reasons why you would want to use the Code index SDK.
1.1 Bulk indexing assemblies
As an enterprise developer I want to regularly index all the assemblies of the overall project I’m working for, so that I save time every day and therefore am more productive
Matt is an enterprise developer who is working on a part of a big project in his organization. His team has a nightly build process using TeamBuild, and everybody can get a drop of the overall project every morning by subscribing to it. Matt uses the architecture diagrams in his day to day work. By doing the drag & drop from the solution navigator pivots, he realizes that Visual Studio is capable of indexing the .Net framework, 3rd party framework, in fact any referenced assemblies, and in particular the assemblies of his drop. However, this takes time to do manually. Therefore, he’d like the drop to be pre-indexed as part of the nightly build so it is available when he arrives at work. He discovers that the Visual Studio Visualization and Modeling Sdk contains a code index Sdk, and he adds a build action to the nightly build to index the whole drop leveraging the indexing tools.
1.2 Benefiting from the indexed information
As an enterprise developer I want to benefit from the indexed information in order to feed it in in-house tools that make me more productive
Matt needs to make a breaking change to an API and wants to warn other teams in his organization that use the API. He does not know exactly which assemblies use this method, but he can find them easily using the architecture tools. Matt’s organization adds attributes to assemblies to specify the team that owns them, so it is easy to work out who to email. However this is a tedious task which he’d like to automate.
Matt knows about the structure of the code index as it is documented in the SDK. He also already has an in-house service that maps team names to email addresses, and he rapidly creates a small in house application that, given a method name, works out the dependent assemblies on that method, automatically creates an email to the correct teams, detailing in a targeted way, the list of affected classes/methods. He just needs to concentrate on explaining the breaking change
1.3 Using a proper SQL server instead of localdb
Tim, the CTO of Matt’s organization would like to understand better the huge codebase of his organization, in particular how all the binaries produced in the different divisions relate to each over, and depend on each other, and what the dependencies are with respect to third party products. He knows that it is possible to index all the binaries in sub trees, but his codebase is huge and therefore he would like to use one of proper SQL servers that are available in his organization. He dreams of all the questions and queries that he’ll ask in order to better understand and communicate the architecture and the quality of his products and of all the problems that would be solved much quicker such as validation the subcontractor’s deliveries, updating the customers of API changes, etc …, understand which tests are ignored and why etc …
He asks one of his reports, Bob, to setup a SQL server database, and have regularly indexed all the product base there, and starts having tools developed to answer the questions and solve the problems he and his directs care about.
2. What is the code index SDK – How to get it?
Before we dive into the details, we need to understand what the code index SDK is, and how to get it.
2.1 What is the code index Sdk?
The code index Sdk is made of:
– MS Build tasks, which need to be used to bulk-index the managed assemblies.
- This series of posts providing an overview of the code index Sdk (we’ll get the MSDN documentation a bit later)
- Samples showing how to access the indexed information will be posted on the Code Gallery, at the same time I write the corresponding blog post.
2.2 How to get the bits?
The code index itself is part of Visual Studio Ultimate / Enterprise since Visual Studio Ultimate 11 Beta. This is the edition that you need to install.
The samples on the code gallery explaining how to leverage the indexed data won’t require anything else. They will just run
But if you wish to bulk index assemblies, you will need the Modeling SDK.:
- From the second update of Visual Studio 2017 RC, the Code Index SDK, which is part o the Modeling SDK is part of the Visual Studio setup. See The visual Studio Modeling SDK is part of Visual Studio 2017
- Before Visual Studio 2017, you will need to install the Modeling SDK (since VS 11 Beta where it was the Visual Studio 11 Beta Visualization and Modeling Sdk (VsVm Sdk). The VsVm Sdk installs itself on top of the Visual Studio Sdk (Vs Sdk).
Therefore you will need to install, in this order:
2.3 What is installed, and where?
2.3.1. Pre Visual Studio 2017
The part concerning the code index is really two assemblies and one MsBuild target file which are installed under the
%ProgramFiles(x86)%\MSBuild\Microsoft\VisualStudio\v11.0\Repository folder (v11 needs to be replaced by the version of Visual Studio you have installed)
|Microsoft.Repository.targets||Sdk targets file|
|Microsoft.Repository.Build.Tasks.dll||Core SDK build tasks.|
|Microsoft.Repository.Build.Runtime.Loader.dll||Plug-in to load managed assemblies|
The target file, named Microsoft.Repository.targets is really worth having a look because it is fully documented and self-explanatory.
2.3.2. From Visual Studio 2017
From Visual Studio 2017, you can install several instances of Visual Studio side by side even if this is the same version with a different or the same edition. Therefore the MSBuild targets are no longer global, but are tight to a specific instance of VisualStudio. For instance, on my machine, where I installed Visual Studio 2017 Enterprise with the Modeling SDK, the files building the Code Index SDK will be located under:
%ProgramFiles(x86)%\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft\VisualStudio\v15.0\Repository
Of course the bits in Italic might change in your installation.
What is next?
Next time, I’ll explain in details how to bulk index assemblies, stay tuned.