For the purpose of testing our C/C++ analyzer PVS-Studio, we often check various open-source projects and publish reports about bugs we have found. It is obvious that we seek projects of large sizes (hundreds of thousands of code lines), as there is little to be tested and caught in just a few dozens of files. We already had opportunities to test large collections consisting of hundreds of small open-source projects, for example sets of test samples for various SDKs and Frameworks. We are especially interested in checking such collections to see how the analyzer supports various specific code constructs, Visual C++ project subtypes, and so on.
Ride the Storm: Navigating Through Unstable Periods / Katerina Rudko (Belka G...
How to unite several separate projects into one general Visual Studio solution (.sln file): One Solution to Rule Them All
1. How to unite several separate projects
into one general Visual Studio solution
(.sln file): One Solution to Rule Them All
Author: Paul Eremeev
Date: 26.04.2013
For the purpose of testing our C/C++ analyzer PVS-Studio, we often check various open-source projects
and publish reports about bugs we have found. It is obvious that we seek projects of large sizes
(hundreds of thousands of code lines), as there is little to be tested and caught in just a few dozens of
files. We already had opportunities to test large collections consisting of hundreds of small open-source
projects, for example sets of test samples for various SDKs and Frameworks. We are especially
interested in checking such collections to see how the analyzer supports various specific code
constructs, Visual C++ project subtypes, and so on.
But projects of this kind have one disadvantage which is not obvious at first sight: they lack a general
project solution file. Each project in these sets is usually independent and has its own solution. Checking
4 or 5 hundred sln files is certainly not a fascinating employment, considering that handling hundreds of
reports thus obtained will be pretty hard too.
Logic tells us that we could create one independent sln file (One Solution to Rule Them All) for all the
project files to unite all the projects we need. But this simple task appears to be not as trivial in case of
Visual Studio because the Add Project dialog allows you to choose only one project at a time! So even if
you are lucky enough to have all the projects lying in one directory, the process of adding them will be
painful all the same.
A quick search revealed at once that we were not alone who had faced this problem. But what do
people usually suggest in this case? Well, they suggest "manually" generating a new solution, open it as
a text file, and add the necessary code lines for each project. What is tricky about this method? You see,
besides having to search through each project to find out its identifiers and configurations, you risk
getting a conflict of dependencies or those very GUIDs of projects (even if only 2 of them). In that case
you would have to manually investigate the whole solution to locate the problem! And writing a
program that would take this all into account yet would be needed just a couple of times, is very
burdensome.
After all, all this functionality can be found in Visual Studio itself - it is that very Add Existing Project that
provides it. If only we could automate the process of calling this command and receiving the list of
files... Well, we can do that. What's more, we can do it by adding just 4 code lines:
EnvDTE.DTE dte = Package.GetService(typeof(EnvDTE._DTE))
as EnvDTE.DTE;
m_dte = (EnvDTE80.DTE2)dte;
2. foreach (string file in Directory.GetFiles(ProjectRoot, "*.vcxproj",
SearchOption.AllDirectories))
m_dte.Solution.AddFromFile(file, false);
As you can see, the object of the EnvDTE80.DTE2 type allows the program to add a project into the
current solution by the file name. And it is quite what we need! Besides, the AddFromFile method also
allows you to manage projects being added by returning references to each of them. Wrapping this code
into a try...catch block will allow you to eliminate all the possible conflicts between separate projects.
What is after all EnvDTE80.DTE2 and how to get it? The DTE (development environment) object is the
top-level object of the Visual Studio Extensibility API which allows you to automate the process of
working in IDE and even extend its capabilities. There are several different ways to get access to DTE,
both from an external process and by creating an extension package or a plugin for the Visual Studio
environment. We have a series of articles on our website on the basics of development of such plugins,
where you can find simple instructions on how to create such a plugin right now!